How to mark Sentry span as a background task?

[punkpeye]

The issue I have is that some requests kick off background activities.

Think something like:

get('/servers', () => {
  setTimeout(() => { startSpan(...); }, 0)

  return doSomething();
})

The issue I am facing is that the span started within setTimeout gets associated with the parent span.

This is a problem when trying to identify things like requests that take a long time because now the request-response time also includes the span that was started without blocking the main request-response.

I think the correct solution is to pass parentSpan: null to startSpan, but wanted to confirm that that's the idiomatic way.

And if I do this, is there some sane way to still comment/leave a link to the parent span?

[MILLERMARRU]

parentSpan: null on startSpan is a real option and does what you'd expect, it detaches the new span from whatever span happens to be active, so it won't nest under (and therefore won't extend the duration of) the request span. That part of your plan is correct.

Worth checking startNewTrace before you settle on parentSpan: null though, it's exported alongside startSpan/withActiveSpan specifically for the "this is genuinely independent work, not just a detached span" case. The distinction matters for exactly the scenario you're describing: parentSpan: null stops the span from being a child of the request span, but depending on how your async context propagates (Node's execution context can still carry the ambient trace through a setTimeout callback even without an explicit parent-span link), it may still end up associated with the same trace as the request, just not nested under it, whereas a background job kicked off via setTimeout conceptually belongs to its own trace entirely, it's not part of that request/response's story at all.

For keeping a breadcrumb back to the originating request without actually nesting the timing: span links are the mechanism for that, a link records a reference to another span/trace without making it a parent for duration-rollup purposes. So the shape that gets you both "doesn't inflate the request's duration" and "traceable back to what triggered it" is roughly: capture the trace/span id you want to reference before entering setTimeout, then pass it as a links entry when starting the new (parent-less or new-trace) span inside the callback, rather than relying on parent-child nesting to preserve that connection.

Given the API surface for links/startNewTrace moves a bit between SDK versions, worth cross-checking against whichever @sentry/* version you're actually on rather than assuming the exact call shape, but the core idea, detach for duration purposes via parentSpan: null or startNewTrace, then re-attach for traceability via a link rather than a parent reference, is the right mental model for what you're trying to do.