Make spans for fetch() more accurate

[lforst]

Problem

In JS fetch() basically runs through 3 stages:

1. fetch() is called and started
2. fetch() resolves - generally meaning status code and response headers are returned
3. The response body streams in (either one chunk or multiple chunks over time)

As of today, the spans we record for fetch calls only entail 1 and 2. Since the web is moving more and more towards streaming (LLMs, React Server Components, Server-Sent Events, ...), it would be quite important to also entail the response streams (3).

Solution Brainstorm

There different approaches we can take:

• Simply extend the spans to also wait for the response body.
• Extend the span to wait for the response body, but attach a child span that tracks the duration until the first byte (entailing 1 and 2). (see comment)

[lforst]

@AbhiPrasad would love to hear your thoughts on having 2 spans, one for total duration, one for time to first byte (not the web vital lol). Would this have downstream implications? I remember the the Java SDK does something similar tracking things like tcp handshake and so on.

[AbhiPrasad]

two spans seems fine to me!

only thing that comes to mind with two spans is which span should the sentry-trace header be generated from? We also should double check the trace view to make sure that thing render properly when you have distributed traces (fetch span is parent of a http.server span). We can fix things as need in the product, just need to ping perf team folks.

[cleptric]

Could span attributes be an alternative to emitting more spans?

[lforst]

Could span attributes be an alternative to emitting more spans?

Yes that makes absolute sense. We should do it like this.

[stefanosiano]

Leaving here the Java PR for reference, in case there are keys we can align on: getsentry/sentry-java#3556
tldr: we added the duration of http operations (expressed in milliseconds) as span attributes to the http.client span