Redis spans become single transactions when using `after` in Next.js

[dcramer]

Summary

While investigating detached spans in our Next.js + Slack app, Codex diagnosed a trace propagation break in the chat SDK async webhook processing pattern. The result is Redis DB spans showing up as root transactions (is_transaction:true) instead of children of the HTTP webhook/request span.

This appears to be a context propagation issue around waitUntil usage with eagerly-started async tasks.

What we observed

• Sentry trace sample: de7433a2d4c4f70153604eb328d6fd5e
• In that trace, DB spans are root spans with is_transaction:true.
• Querying the trace:
  • DB spans with missing parent span id: 6
  • DB spans with non-empty parent span id: 0
• In the last 24h, top db “transactions” include Redis commands like:
  • GET chat-sdk:cache:...
  • SISMEMBER chat-sdk:subscriptions ...
  • SET chat-sdk:lock:...

That indicates the DB spans are detached from the intended request/workflow parent span.

Why this seems to happen

1) Request span exists in webhook handler

Our route wraps webhook handling in a request span and passes a background function:

withSpan("http.server.request", "http.server", ..., async () => {
  const response = await handler(request, {
    waitUntil: (task) => after(() => task),
  });
  return response;
});

2) chat SDK eagerly starts async work before scheduling

In chat processMessage (and similar methods), task is started immediately:

const task = (async () => {
  const message = ...
  await this.handleIncomingMessage(...)
})().catch(...)

options?.waitUntil?.(task)

By the time waitUntil/after runs, work is already in flight and may no longer be bound to the originating active span context.

3) Redis spans are emitted inside that async pipeline

handleIncomingMessage performs state adapter operations (get/set/lock/isSubscribed/...), so those DB spans can become root spans if parent context is absent.

Expected behavior

DB spans from webhook message processing should remain parented under the request span (or at least under the same trace root), not become detached root transactions.

Suggested direction

A lazy background scheduling API in chat could avoid eager task startup and preserve context:

• Add something like runInBackground?: (run: () => Promise<unknown>) => void
• If provided, SDK should pass a thunk and let caller execute it in the desired context.
• Keep existing waitUntil(task) for backward compatibility.

This allows frameworks/runtimes to run deferred work inside a captured active span context (e.g. withActiveSpan).

Environment

• @sentry/nextjs: 10.40.0
• next: 16.1.6
• chat: 4.14.0
• @chat-adapter/slack: 4.14.0
• @chat-adapter/state-redis: 4.14.0

Additional note

This diagnosis and root-cause mapping were performed by Codex during a deep source + trace analysis.

[linear]

JS-1812

[dcramer]

My first attempt at an unverified fix getsentry/junior@36afd66

[JPeer264]

Quite interesting. I actually got a reproduction working here: https://github.com/JPeer264/temp-next-after-repro

Example trace: https://sentry-sdks.sentry.io/explore/traces/trace/b9e828a22bb9d7a935a7434f2a46e068

It seems that adding the after from next/server is the reason for this behavior. It has nothing to do with the chat sdk itself.

I also tried to apply the fix as given above, but this didn't change anything. Just to confirm, did it change anything on your end?

[dcramer]

I'm not convinced it fixed it. At the very least i still have wack transactions as db spans.

[JPeer264]

tl;dr;

There are 2 solutions:

• Wrap after in its own span
• Use span streaming once it is available

---

Alright. I dug deeper into this. That has nothing to do with Next.js, nor with Chat. This is how we are handling transactions currently.

Problem

So there is a request, and there is something happening after a request (= whatever happens in after/ waitUntil). We usually have a root span for the request and capture everything within as "children" and send this as one transaction. Once the request finishes we end the root span and flush it, but in practice there is still something happening, as Redis will be processed eventually (this is btw not Redis related and would happen with every span). The spans are now created after the root span ended and internally we don't find any "span parent" anymore in-memory (BUT we do have the actual parent id - that is why it is showing up correctly in the UI).

Now the funky part: Since there is no span which "captures" these child spans, they are all seen as "root span" and therefore been send as individual transactions.

This graph shows a transaction when the call is awaited inline. All spans are created within the root span (the longest on the top) and are therefore 1 single transaction:

This graph, however, shows the use case where after is getting called. The root span ends at some point and every span which ends after the root span are marked as single transaction, as there is no parent anymore here.

Proposal

We can't create only 1 transaction (there must be two with our current implementation), as we don't know when or if the after/waitUntil is actually resolving. So we have to send one for the request, and another when everything inside after is eventually finished. So the solution could be: Wrapping after in its own span:

after(Sentry.startSpan({ name: "after" }, () => doRedisWork(requestId)));

With that we have 2 transactions:

1. The request itself
2. The after function (as this is now their "parent"/"root span")

Next steps

I'll discuss with the team if we would like to add that span wrapping in our SDK and come back with an answer next week. In the meantime you can already wrap this yourself to minimize the transactions.

---

FWIW. Span streaming would that issue entirely (but this is not available at this point in time).

[JPeer264]

tl;dr; We discussed this internally and it really is a technical limitation right now. We are now documenting this behavior with a best practice to mitigate this issue. I have created an issue that will document this: getsentry/sentry-docs#16815

---

The background to our decision. after does take a promise, which is pending or settled. Theoretically we could potentially monkey-patch after and wrap it with a Sentry.startSpan automatically, but this doesn't solve anything and makes things just worse.

Why? There is no way to use the product correctly anymore. As the only possible way to use after is to pass a promise:

after(myPromise())

With that the myPromise is not executed within after but with the closure outside. Therefore our Sentry.startSpan would create a span, but doesn't have any children, as the spans inside myPromise would be categorized to the wrong parent. See with the following screenshot (patchedAfter has now the after monkey patched):

// monkey-patched example:
const patchedAfter = (task: AfterTask<unknown>) => Sentry.startSpan({ name: "patchedAfter" }, () => task);

---

The real solution? If after and waitUntil changes to take only a function that returns a promise instead of just taking a promise (right now after takes both, a function and a promise, and waitUntil only a promise, we could monkey-patch it and execute the task inside our startSpan:

const patchedAfter = (task: () => AfterTask<unknown>) => Sentry.startSpan({ name: "patchedAfter" }, () => task());

This is btw also true for Cloudflare and waitUntil. I already tried to propose it here: cloudflare/workerd#6055 (comment)

---

Closing this now with the reasons mentioned above