Improve ignoreSpans behaviour in Browser SDKs #17451
Description
Description
The initial implementation of ignoreSpans retroactively, at event processing time, removes spans matching the filter criteria from the trace and re-parents existing spans. While this works reasonably well in server SDKs, where the root span always has a defined start and end point, it doesn't work well in browser sdks.
This is because the root spans created from our browser SDKs (pageload and navigation spans) are almost exclusively idle spans, meaning they have a defined start point but their end point is debounced until no more child spans are added (with a couple of timeout options to keep things at bay of course).
This leads to the problem that if we filter out spans via ignoreSpans that initially prolonged the pageload (et al.) root span, the root span appears way longer in duration than the remaining child spans. This effectively makes the root span duration even more unactionable than it is already.
Short-term, we have 2 possibilities to improve this:
- Apply
ignoreSpansprior to starting any span. This would be logical but is only possible in browser-land. Meaning, the behaviour of this option would significantly differ between browser and Node/OTel-based SDKs. - Apply another round of idle span end timestamp adjustment at at post-event-processing time. We already adjust the end time of the idle span to the longest running child span but we'd need to do another pass of this adjustment after applying
ignoreSpanswhere we currently do it.
I'm kinda leaning towards 1 for now, mainly because we can but equally unhappy to go with either option.