Skip to content

How do you follow one booking across the API and asynchronous worker?

1 min read · main part only; folded sections are optional

After this you can answer: How do you follow one booking across the API and asynchronous worker?

A customer can copy the response header from the browser network panel. The API request logger uses the same request ID. The durable booking message carries the original correlation ID, so the relay and consumer do not lose the original request context when work happens later.

Each worker call adds awsRequestId; each message adds sqsMessageId and receive count. The business job key identifies the confirmation independently of the queue envelope. Re-published copies can therefore have different message IDs while belonging to one booking.

Search the saved follow-one-request query over the relevant groups and inspect timestamps in order. On idempotent HTTP replay, the new request ID may differ from the original outbox ID, so booking ID is also necessary. Supplied correlation IDs are validated but can be reused by callers; do not treat them as an authentication claim or guaranteed unique business key. Avoid logging raw messages because they contain email addresses.

What if the HTTP response never arrived?
Find the booking through an authorized business lookup and search its business identifiers. A missing client header must not make the booking untraceable.
Does email sent mean the user received it?
It means the send operation was accepted according to the mailer path. Inbox delivery is a separate provider outcome.
Why add tracing later?
Spans can measure time in dependencies and parent-child relationships. Current correlation logs link events but do not automatically provide those timings.

Read the path chapter, select the relevant map piece →, then inspect apps/api/src/http/correlation-id.ts → correlationIdFor. Work through the related case for a diagnostic example.

Read this book online: https://book.theversehub.in/