WEB / CASE async-result
A 202 returned. Why isn’t the job complete?
Connect HTTP acceptance, queue delivery, worker processing, persistence and the user view as separate evidence layers.
Observation file
The Atlas export fixture returns 202 with alias export-01. The producer event is accepted; there is no worker observation or completed result in the result store. This alias is not a real job or user record.
Acceptance is not completion
202 does not establish completion. Queue delivery, consumer processing and a durable result are separate stages. A missing worker event also does not prove nonexecution; establish observation scope and the time window.
Retries may permit duplicate delivery without proving duplicate business effects. Idempotency keys, transaction boundaries and result records answer that question separately. An HTTP correlation ID does not automatically provide idempotency.
Operation and verification
Compare fixed normal completion, delayed consumer and repeated-delivery branches. The UI distinguishes accepted, running, completed and failed. Authorization context is carried deliberately to the worker and rechecked for result reads; enqueueing proves neither check.
YOUR TURN
Work through this story.
Predict the outcome, find the evidence boundary, and explain it in your own words.
export-01 has a 202 and an accepted producer record, but no worker/result observation. Which finding preserves the evidence boundary?
Selected observations from the synthetic case file
- teaching job alias
- export-01
- HTTP status
- 202
- producer event
- accepted
- worker observation
- not observed
- result store
- completed result not observed
- The 202 proves completion; the result is merely hidden.
- Acceptance is observed; completion is not established, and worker nonexecution is not proven either.
- With no worker record, the consumer definitely never ran.
Read the explained answer
Acceptance is observed; completion is not established, and worker nonexecution is not proven either. — A 202, queue delivery, consumer processing and durable result are separate evidence layers. The narrow finding is observed acceptance without verified completion in this file; missing worker records require an observation-scope assessment.
A repeated-delivery branch is observed. Which distinction is required before claiming the same business effect happened twice?
- An HTTP correlation ID automatically prevents every duplicate effect.
- Two deliveries always mean two business effects.
- Record redelivery separately; compare idempotency, transaction and result evidence for the effect.
Read the explained answer
Record redelivery separately; compare idempotency, transaction and result evidence for the effect. — The false conclusion comes from treating transport/queue repetition as a business outcome. Correlation joins events without automatically providing idempotency or transaction behavior.
Write a regression plan covering results and authorization for normal completion, delayed consumption and repeated delivery.
Read the explained answer
In the normal branch, correlate acceptance, consumer processing and a completed durable result separately. With a delayed consumer, distinguish accepted/running UI states from completion and define a time window for missing observations. For repeated delivery, compare transaction/idempotency/result evidence for the same operation without assuming a duplicate effect. Authorization context is carried deliberately to the worker and permission is reevaluated when reading the result. Enqueueing is evidence of neither authorization check.
□ Are acceptance, processing and durable results linked through separate observations?
□ Are the delayed branch’s time window and UI-state limits explicit?
□ Are repeated delivery and duplicate effects distinguished?
□ Are worker-context and result-read authorization checks independent?
Lessons connected to this case · 8
Return to the case with these lesson concepts. Connections do not add observations to the case record; they help examine its responsibilities together.