When to use this pattern
Use this pattern when an asynchronous job is late, retried, duplicated, or disconnected from the request that submitted it.
Investigation flow
- Identify the job or publication, message destination, and producer operation. Preserve trace context in supported message metadata.
- Find the corresponding receive and processing operations using message identity, job identity, and recorded links or parent relationships.
- Separate queue residence, delivery attempts, processing, and acknowledgement. Use broker evidence or comparable timestamps to assess waiting.
- Inspect retries, batch membership, and fan-out before deciding that several consumer operations describe the same execution.
Required fields
| Field or dimension | Purpose |
|---|---|
| job ID and message ID | Distinguish a logical workflow from a particular publication or message; delivery identity rules vary by broker. |
| messaging destination and environment | Avoid joins across queues, topics, or environments with similar names. |
| propagated creation context and span links | Preserve the recorded producer association even when a consumer uses a separate trace. |
| attempt, delivery, and processing observations | Separate retries and queue waiting from consumer execution. |
Worked example: The job waits in the queue instead of running slowly
An export is published and begins processing about 20 seconds later, but its consumer work takes only 80 ms. Broker backlog and available consumer capacity are useful next comparisons. Publication and processing identifiers keep the job connected without counting a retry as a second completed export. The 20-second gap needs trustworthy timing evidence before it can be attributed entirely to queue residence.
| Evidence | Observation |
|---|---|
| Producer | The export publication carries job identity and supported trace context. |
| Consumer | Processing is recorded for the same job and message association, possibly in a linked trace. |
| Timing | Short execution with delayed start directs attention to queue and delivery evidence. |
Limitations and false matches
- Consumers can use span links and separate traces; one shared trace ID is not a universal requirement.
- A batch can contain messages from several producers. One parent cannot represent every originating operation.
- Retry, redelivery, and fan-out can create several processing observations for one publication; message ID does not prove unique successful execution.
- Clock skew makes subtraction across hosts unreliable. Message metadata and current semantic-convention support differ across libraries.
Verification checklist
- Publish a test message and confirm its context or span association survives delivery to the consumer.
- Test a retry and confirm attempts remain distinguishable while the logical job stays connected.
- Test a batch or fan-out path when used by the application, and verify all expected producer associations are retained.
Supported by
Documented examples, not an exhaustive compatibility list. Features require suitable instrumentation and configuration; availability can depend on the runtime, backend, and subscription.
- OpenTelemetry — Messaging conventions describe producer and consumer associations, including span links. These conventions are evolving; verify the version and behavior emitted by the chosen library.
Related signals
Related concepts
Related patterns
Related guides
FAQ
Must producer and consumer spans belong to one trace?
No. A recorded span link can associate a consumer operation with the message creation context in another trace. Check what the instrumentation emits and what the backend displays.