Editorial review pendingon version support under review
Action boundary
Before you act
- Expected result
- Replaying one synthetic event creates no second external side effect and leaves an inspectable decision record.
- Failure mode
- A timeout is mistaken for no delivery and a retry repeats an external action.
- Rollback
- Stop retries, mark the event unresolved, and reconcile using the provider-specific delivery receipt.
Orient
“Sent” is too vague. Record whether an event was accepted, queued, attempted, acknowledged, or confirmed. Use the provider’s event identity where available; otherwise create an owned idempotency key before the side effect.
Perform
Define a decision record with event ID, verified sender, route version, approval ID, outbound intent, provider receipt reference, state, and timestamp. Replay the same synthetic event twice.
Check
The second run must find the first decision before delivery. A timeout remains unresolved until provider evidence says otherwise; do not call it a failure or success on a hunch.
Debug order
Trace event identity → endpoint verification → route decision → idempotency record → approval decision → outbound receipt. If identity or intended recipient is unproved, stop.
Continue
Use those records to make human approval explicit in Lesson 5.1.
Lesson checkpoint
Ready to move on?
Mark this lesson complete when you can apply its outcome without relying on the examples above.