Span `timeline_exceeded` status can be misleading

[bruno-garcia]

For the first 2 years of the performance product, Transactions required a complete list of spans (aka: spans needed a start and end timestamps) to be accepted by Sentry.

For that reason, all SDKs had to deal with spans that were not yet completed, when a transaction was finished. A pattern at the time was to finish the span using the timeline_exceeded status.

In 2021, we had a DACI to change that behavior. And in 2022 Relay was changed to no longer required all spans to be completed. Giving flexibility to what happens in those cases. Even though at this time it continued with the behavior of setting a end timestamp matching the transaction end timestamp and status timeline_exceeded:

• https://github.com/getsentry/relay/issues/1244

Problem with these solution:

• We consider span duration on the Requests module, and possibly other parts of Sentry
• Span duration stats are considering a span duration that is not accurate
• ... anything derived from spans duration and/or status

This came up recently internally with @thinkocapo: https://www.notion.so/sentry/HTTP-Spans-Deadline-Exceeded-Skewing-Insights-Requests-edab31417a894c5abba14e0d4c3f18e3

[getsantry[bot]]

Routing to @getsentry/product-owners-performance for triage ⏲️