ResolveOpsFind the destination record
Suppose a transfer times out after the destination has saved the record. The source sees a failure; the destination has already acted. Sending the same request again could create a second record unless the connection or application recognizes it.
Trace a sample from its source identifier through the request to the destination. Establish whether acceptance means queued, saved or available for the next task, and use those states consistently in monitoring and recovery instructions.
Test repeat requests and late updates
A repeated creation request may need to return the existing record. An update may need a version check to avoid replacing a newer correction. Agree how each event should behave before testing the failure cases.
| Test case | Evidence the operator needs |
|---|---|
| Timeout after the destination accepted the request | Destination lookup by a stable source reference, plus the original request identifier |
| The same event arrives twice | The destination’s duplicate-handling behavior and the identifier used to recognize the event |
| A record is corrected while an older update is waiting | Version or event ordering and the rule that prevents the earlier update overwriting the correction |
| A bulk transfer stops halfway through | A record of completed items and a way to resume without repeating accepted work |
Set a stopping condition
When the destination result cannot be established, hold the item for investigation. Collect the source reference, request identifier, timestamp and response. The runbook should identify who can check the destination and which evidence allows a retry.
Record who can authorize a manual correction and what evidence they need. Permission to edit a screen does not establish authority to amend an invoice, release stock or change a customer record.
Try the runbook with the support operator
Have the person responsible for support follow the recovery instructions using their normal permissions. Check that they can find the record, interpret its state and carry out the permitted action. A step that still needs the developer should be recorded as a dependency.
Link to the approved access method instead of putting credentials in the instructions. Keep a record of the recovery action and its result so the next operator can tell what has already been attempted.