Proposed flow for this scenario
- Receive and current receipt
- Useful work
- Durable completion evidence
- Delete using current receipt
- Inspect redelivery
- Recognize prior completion
This flow describes a design to evaluate. Follow the supported console workflow below to practice with local resources. Its scope appears with the controls; no cloud resources are provisioned.
Decision checkpoints
| Choice | Fits when | Watch for |
|---|---|---|
| Successful current-receipt deletion | Useful work is durably complete and the current delivery can be acknowledged. | Acknowledging before the required result exists. |
| Idempotent recovery on repeat | A retry can detect completed or ambiguous work. | Treating every new receipt as a new customer operation. |
Separate three meanings of success
In synthetic LetX, a worker receives a job, writes an artifact and then loses the acknowledgement response. “Processed” may describe useful work while the queue still contains a delivery. Record the stable job identity separately from the receive receipt.
Check whether deletion was attempted and whether its result was accepted for the intended queue and current receipt. A later receipt belongs to another delivery attempt. Do not use an old token as the durable identity of the business effect.
Visibility is a lease, not completion storage
If the job outlasts the lease, another attempt can become eligible. Choose and, where appropriate, extend visibility for the processing path, but do not describe the lease as a guarantee of exactly-once effects.
A worker crash after external success remains ambiguous even with a longer lease. The replacement should inspect a durable completion record, stable result location or provider-supported idempotency outcome before repeating the effect.
Run the local repeat-delivery drill
Send one synthetic job and receive it in the console. Leave it unacknowledged, advance simulated time beyond visibility and receive it again. Compare its operation content and new receive state, then delete with the current receipt.
Repeat the exercise with a durable synthetic completion decision in the lesson notes: the second worker should recognize that result rather than create another one. The local queue model has selected lease and receipt semantics, no real worker and no simulation of every rare distributed duplicate in AWS.
Changed scenario and verification
Question: the artifact was written, but the worker never recorded its completion. Is deleting the delivery immediately on the retry always safe? Not without establishing the intended usable result. Resolve the incomplete or ambiguous state, then acknowledge according to the recovery rule.
Inspect useful completion, repeated attempts and deletion errors together. Use the queue console below to inspect another synthetic delivery and acknowledge its current receipt; useful worker completion remains a scenario decision. A falling visible-message count alone does not prove customers received the correct artifacts.
Practice the supported console workflow
Sources and scope
Reviewed against these official references. The model’s supported scope appears alongside its controls.
How we review explanations