Turn a database deadlock into a repeatable test

Start with the disputed behavior

This job fits backend teams investigating intermittent transaction failures. Before touching code, write the behavior under review: recreate the lock order with two controlled sessions. Include the repository revision, environment, representative fixture, reviewer, and a clear stop point.

Record a plain baseline

Run one ordinary case first and save transaction steps, lock waits, deadlock reports, retry behavior, and final row values. Keep the input small enough that another developer can inspect it without special production access. The baseline tells you whether the test setup itself is trustworthy.

Review record

Scroll sideways to read every column on a small screen.

Recreate the case people tend to miss

The useful stress case is simple to state: the retry succeeds but repeats an external side effect. Change only one condition at a time. Note the request or event, prior state, observed transition, final state, and the clock used for every timestamp.

Put the correction beside the failure

Trace the result to the narrowest responsible boundary. Put the regression check close to that boundary, make the smallest defensible correction, and rerun both the ordinary and troublesome cases. Record nearby behavior that remains outside the brief.

Keep authority with the system owner

An offshore developer may prepare fixtures, investigate the failure, implement a reviewed patch, and collect proof. Internal owners retain protected credentials, architecture exceptions, irreversible data work, incident disclosure, and the production release decision.

Write a handoff that survives a time-zone change

The handoff should name the starting and ending revisions, changed files, fixture data, commands, passed and skipped checks, remaining uncertainty, rollback approach, and reviewer. It should answer the original question about how to recreate the lock order with two controlled sessions.

Questions about assessing Philippine developers