Back to Changelog

Asynchronous Transactions

Trace asynchronous transactions across messaging systems.

We have released two new dedicated sections on the Transaction screen that allow you to trace asynchronous transactions:

  • Consumed By — the downstream transaction(s) that consumed the message(s) this transaction sent.
Consumed By Transactions Section

  • Produced By — the upstream transaction(s) that sent the message(s) this transaction consumed.
Produced By Transactions Section

Why is this needed?

Asynchronous transactions are transactions triggered independently of the transaction that originally initiated them — for example, a Lambda function reading messages from an SQS queue, or an ECS task consuming messages from a Kafka topic.

Unlike a typical synchronous call (e.g. an HTTP request), these transactions aren’t a direct extension of the transaction that triggered them. This creates two challenges for standard trace visualization:

  1. Duration doesn’t roll up naturally. It wouldn’t make sense to include the duration of a downstream transaction (e.g. an SQS consumer) as part of the duration of the transaction that produced the message (e.g. the producer Lambda) — the two run independently, often at completely different times.

  2. A single transaction can have multiple sources. A consumer might process a batch of several messages in one invocation, and those messages could have been sent by different upstream transactions.

For these reasons, asynchronous transactions aren’t shown in the Flow section of the triggering transaction the way a normal synchronous call would be. Instead, they are show in these new Consumed By and Produced By sections.

Each entry in the sections includes the transaction summary and a link to the detailed view for that transaction, so you can navigate between them directly. This makes it easy to answer questions such as:

  • Did any of my downstream async services fail?
  • Which transaction sent the message that triggered this one?