Deadlock Reproduction Test Prompt

This prompt is for backend engineers and SREs who have strong evidence of a deadlock in production—stack traces, thread dumps, or database lock graphs—but cannot yet reproduce it locally or in a staging environment. The job-to-be-done is to generate a minimal, repeatable test scenario that triggers the same circular wait condition observed in production, using the transaction patterns, lock ordering, and isolation levels extracted from the codebase and incident artifacts. The ideal user has access to the relevant source code, database schema, and production diagnostic data (e.g., SHOW ENGINE INNODB STATUS, pg_locks, or thread dump files). Do not use this prompt for general concurrency testing, load testing, or performance tuning; it is specifically designed to isolate and reproduce a deadlock, not to measure throughput or latency.

The prompt requires several concrete inputs to be effective. You must provide the transaction code paths involved in the deadlock, including the order of statements and any conditional branching. Include the database isolation level configuration and any explicit locking hints (e.g., SELECT ... FOR UPDATE, LOCK TABLE). Supply the production deadlock graph or equivalent diagnostic output that shows which transactions were waiting on which locks. If available, include the application's connection pooling settings and transaction timeout values, as these often mask or exacerbate deadlock timing. The prompt works best when you can isolate two or three specific transactions that form a cycle; avoid dumping entire service codebases without first narrowing the suspect transactions through log analysis or thread dump inspection.

This prompt is not a substitute for production deadlock analysis. It assumes you have already identified the candidate transactions and need help constructing a deterministic reproduction. The generated test will include explicit lock acquisition ordering, timing controls (e.g., Thread.sleep or await barriers), and assertions that validate the deadlock occurs as expected. After generating the test, you must run it in an environment that matches the production database version and configuration. If the test does not reproduce the deadlock, re-examine your isolation level assumptions and the completeness of the transaction code paths you provided. The next step is to use the generated test as a regression anchor: once you apply a fix, the test must pass by demonstrating that the deadlock no longer occurs.

This section provides a copy-ready prompt template that you can adapt for your own deadlock reproduction workflows. The template is designed to accept structured inputs about your system's transaction patterns, lock ordering, and isolation levels, then produce a minimal, reproducible test case. Use the square-bracket placeholders to inject your specific code snippets, database schemas, and configuration details before sending the prompt to the model.

textCopy
You are a concurrency testing specialist. Your task is to generate a minimal, reproducible test case that triggers a deadlock condition based on the provided context.

## INPUT
[TRANSACTION_PATTERNS]

[LOCK_ORDERING_ANALYSIS]

[ISOLATION_LEVEL_CONFIGURATION]

## CONSTRAINTS
- Produce a self-contained test that can run in isolation.
- Use the same database driver, ORM, or connection library already present in the repository.
- The test must fail reliably when the deadlock condition exists and pass when it is resolved.
- Include explicit setup, execution, assertion, and teardown steps.
- Do not introduce new dependencies or test frameworks unless absolutely necessary.

## OUTPUT_SCHEMA
Return a JSON object with the following fields:
{
  "test_name": "string, descriptive name for the test case",
  "language": "string, programming language of the test",
  "framework": "string, test framework to use",
  "setup_code": "string, code to prepare the required state (tables, rows, connections)",
  "test_code": "string, the concurrent execution code that triggers the deadlock",
  "assertions": ["string, list of assertions that verify deadlock behavior"],
  "teardown_code": "string, code to clean up resources after the test",
  "reproduction_steps": ["string, ordered list of human-readable steps to reproduce"],
  "expected_deadlock_graph": "string, description of the expected wait-for cycle",
  "risk_notes": "string, any assumptions or environmental dependencies"
}

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

Generate the test case now.

To adapt this template, replace each placeholder with concrete information from your investigation. For [TRANSACTION_PATTERNS], paste the relevant code blocks or pseudocode showing how transactions acquire and release locks. For [LOCK_ORDERING_ANALYSIS], include your findings on which resources are locked in which order across concurrent sessions. For [ISOLATION_LEVEL_CONFIGURATION], specify the database isolation level, any lock hints, and connection pool settings. The [EXAMPLES] placeholder should contain one or two existing test patterns from your repository so the model can match your team's conventions. Set [RISK_LEVEL] to "low", "medium", or "high" to control how conservative the generated assertions should be. After generating the test, always validate that the output matches the OUTPUT_SCHEMA before integrating it into your test suite, and run the test in an isolated environment to confirm reproducibility.

The deadlock reproduction prompt is designed to be called from a backend testing harness, not run manually in a chat interface. The harness should supply the prompt with a structured [TRANSACTION_PATTERNS] payload extracted from database logs, lock-monitoring tools, or ORM query traces. The model returns a structured test scenario that the harness then executes in an isolated test environment. Because deadlock reproduction involves running concurrent transactions that intentionally contend for locks, the harness must enforce strict isolation: never run generated tests against production databases, and always use a dedicated test instance with snapshot or restore capability.

Wire the prompt into your application with a validate → execute → verify loop. First, parse the model's JSON output and validate that the reproduction_steps array contains executable SQL or ORM operations, that expected_deadlock_point identifies a specific lock resource, and that isolation_level matches a supported value in your test environment. If validation fails, retry the prompt once with the validation errors appended to [CONSTRAINTS]. Before execution, the harness must snapshot the test database state. Execute the generated steps using two or more concurrent sessions as specified in the concurrency_model field. After execution, verify that the deadlock actually occurred by checking database deadlock logs, lock-wait timeouts, or the error codes returned to the sessions. If the deadlock does not reproduce within the specified timeout, capture the actual lock-wait graph and feed it back to the model as [OBSERVED_BEHAVIOR] for a refinement pass.

For model choice, prefer models with strong SQL and concurrency reasoning. The prompt's structured output schema and step-by-step lock-ordering analysis benefit from models that can reason about transaction interleaving. Set temperature low (0.0–0.2) to maximize reproducibility of the generated test steps. Log every generated scenario, execution outcome, and reproduction success rate to build a regression suite over time. Never allow the harness to execute generated tests that include DROP, TRUNCATE, or unqualified DELETE statements—add a pre-execution safety filter that rejects destructive operations. If the prompt is used in a CI pipeline, gate deployment on successful deadlock reproduction for known lock-ordering bugs, and require human review for any generated test that proposes changing isolation levels in production configuration.