Parallel Execution Conflict Detection Prompt

This prompt is designed for CI platform engineers and QA infrastructure teams who need to diagnose concurrency flakiness in parallel test suites. When test suites pass reliably in serial execution but fail intermittently under parallel workers, the root cause is often resource contention: port binding conflicts, shared file system access, database state collisions, or test worker interference. The prompt analyzes structured test execution logs to identify conflict pairs and produce isolation recommendations.

Use this prompt when you have execution logs from multiple parallel workers, timestamps, and failure signatures. The ideal input includes worker-level log segments with timestamps, resource identifiers (ports, file paths, database keys), and failure stack traces. Do not use this prompt for single-worker flakiness, logic errors in test assertions, or environmental drift unrelated to concurrency. The prompt assumes you have already collected parallel execution traces and can provide worker-level log segments. For single-worker failures, use the Flaky Test Failure Log Analysis Prompt instead. For environment-specific drift, use the Test Environment Dependency Audit Prompt.

Before invoking this prompt, verify that your test suite passes consistently in serial mode and only fails under parallel execution. Gather logs from at least two workers that exhibit the failure pattern, including timestamps synchronized across workers. If your CI system does not provide worker-level log separation, instrument your test runner to tag log entries with worker IDs before collecting traces. The prompt's output is only as reliable as the temporal precision of your logs—timestamp skew across workers will produce false conflict pairs.

The prompt outputs conflict pairs with evidence, not definitive root cause verdicts. Each identified conflict pair should be treated as a hypothesis requiring reproduction. After receiving the output, attempt to reproduce the conflict by running the identified test pair in isolation under the suspected resource constraint. If reproduction succeeds, apply the recommended isolation strategy (port randomization, temp directory scoping, database namespacing) and verify the fix across multiple parallel runs before closing the investigation.

This section provides the core prompt you will paste into your AI harness. It is designed to receive structured test execution logs and return a list of conflict pairs, each with evidence and an isolation recommendation. The prompt uses square-bracket placeholders that you must replace with real data before sending it to the model. Do not treat this as a static text block; it is a template that expects dynamic inputs from your CI system's log aggregator.

textCopy
You are a CI reliability engineer analyzing parallel test execution logs for concurrency conflicts.

Your task is to identify pairs of tests that interfere with each other when run in parallel. Look for resource contention, port conflicts, shared file system access, database state pollution, and test worker interference.

## INPUT LOGS
[TEST_EXECUTION_LOGS]

## TEST SUITE CONTEXT
[TEST_SUITE_METADATA]

## OUTPUT SCHEMA
Return a JSON object with a single key "conflicts" containing an array of conflict objects. Each object must have the following fields:
- "test_pair": ["test_name_1", "test_name_2"]
- "conflict_type": "port_conflict" | "file_lock" | "db_state_pollution" | "shared_memory" | "external_service_rate_limit" | "worker_resource_exhaustion" | "other"
- "evidence": "Direct quote or timestamped log excerpt showing the conflict."
- "shared_resource": "The specific resource in contention (e.g., port 5432, /tmp/cache.lock, users table)."
- "severity": "high" | "medium" | "low"
- "isolation_recommendation": "A concrete, actionable suggestion to isolate these tests (e.g., use dynamic ports, mock the service, add a transaction rollback, run in separate workers)."

## CONSTRAINTS
- Only report conflicts where you have direct evidence in the provided logs. Do not speculate.
- If no conflicts are found, return {"conflicts": []}.
- Do not include tests that merely ran slowly unless the slowness is directly linked to a resource conflict.
- Prioritize conflicts that caused actual test failures over warnings.

To adapt this template, replace [TEST_EXECUTION_LOGS] with the raw, timestamped output from your parallel test workers. The [TEST_SUITE_METADATA] placeholder should include the test framework, execution environment, worker count, and any known shared resources. For high-risk CI pipelines where a bad recommendation could mask a real flake, always route the model's output through a validation step that checks the JSON schema and confirms that each evidence string can be found in the source logs. If the model returns a conflict you cannot verify, flag it for human review before applying any isolation changes.

The Parallel Execution Conflict Detection prompt is designed to run as a post-hoc analysis step in your CI pipeline, not as a real-time gate. After a test suite completes with one or more failures, collect the full test execution logs—including worker IDs, timestamps, and resource access patterns—and feed them into this prompt. The model returns a structured conflict report that your pipeline can parse, store as a CI artifact, and surface to the on-call engineer or platform team. Do not block merges on this analysis; use it to enrich failure investigations and build a historical record of concurrency issues across runs.

To integrate, wrap the prompt in a lightweight harness that handles three concerns: input assembly, output validation, and retry with degradation. For input assembly, extract the relevant log sections—test names, worker assignments, start/end timestamps, and any resource-level log lines (port binds, file locks, shared directory access). Pack these into the [TEST_EXECUTION_LOGS] placeholder. If your CI system emits structured JSON logs, pre-process them into a compact text representation that preserves ordering and worker identity. For output validation, define a JSON schema that matches the expected conflict report shape: a list of conflict pairs, each with test_a, test_b, conflict_type (one of port, filesystem, database, cache, environment_variable, other), evidence_lines, and isolation_recommendation. Reject outputs that fail schema validation or contain hallucinated test names not present in the input logs. For retry logic, attempt up to two retries with temperature variation (0.1, then 0.3) if validation fails. If the model consistently fails to produce valid output, degrade gracefully by emitting a partial report with a validation_failed flag and raw model output attached for manual review.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window—test execution logs for parallel suites can easily exceed 8K tokens. Claude 3.5 Sonnet or GPT-4o are good defaults. Avoid smaller or faster models that may miss subtle interleaving patterns. If your logs exceed the context window, pre-filter to only failed tests and their immediate neighbors in the execution timeline, or chunk by worker and run the prompt per worker pair. Log every invocation: input token count, output schema validity, conflict count, and latency. This telemetry helps you tune the prompt over time and detect drift in model behavior. Finally, never treat the model's output as authoritative without human review for critical pipelines—conflict detection is a diagnostic aid, not a replacement for deterministic concurrency testing tools like thread sanitizers or deterministic simulation frameworks.