What happened after the timeout?

1. Reproduce the failure

The deliberately faulty handler trusted a successful response and appended its output. It did not compare the requested subject with the returned subject. Calling it again appended again. The baseline test reproduced both defects: the wrong record was accepted and a retry duplicated a write.

2. State the promise precisely

Within this local transaction boundary: one tenant and one logical job may commit one matching result. Reusing that job with a different payload is a conflict, not another write. The result must survive reopening the database.

A request to another provider lies outside that transaction. There, we need its documented idempotency mechanism or an explicit reconciliation path. A local database cannot make an unrelated remote action atomic.

3. Change the control, not the success message

1. Verify the signed request and permitted tenant before processing it.
2. Canonicalize the known fields and bind their fingerprint to the tenant/job identity.
3. Reject a mismatched subject before writing.
4. Use a database uniqueness boundary and transaction for the local result.
5. On an identical retry, return the persisted result. On conflicting content, reject.

4. Break the acknowledgement on purpose

The test commits a valid row, then returns a simulated 503 instead of acknowledging success. It sends the same job again and asserts the response is a replay of the stored result—not a new row. It also reopens the database and repeats the replay check.

5. Inspect the actual destination

The run checks the stored rows and independently compares the delivered file bytes. Twenty concurrent HTTP deliveries of the same job leave one committed row. Another check uses a newly generated subject rather than only the bundled example.

15 named checks passed in the recorded run of September 28, 2026 UTC. The public summary carries the original test timestamp and source/test fingerprints. It does not expose the private repair implementation.

What this changes for your repair

We start with your expected result, find the first boundary where reality diverges, and agree one reproducible acceptance target. Your system may need a different mechanism. The useful deliverable is a tested change plus an observable downstream outcome—not this fixture transplanted blindly.