Skip to content

Improve ignoreSpans behaviour in Browser SDKs #17451

Closed

Description

@Lms24

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:

  1. Apply ignoreSpans prior 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.
  2. 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 ignoreSpans where we currently do it.

I'm kinda leaning towards 1 for now, mainly because we can but equally unhappy to go with either option.

Activity

  1. linear commented on Aug 25, 2025

    @linear
  2. mydea commented on Aug 29, 2025

    @mydea
    Member

    I think the main reason why applying this at start time may not work well is that span attributes may not be fully finalized at this point 🤔

  3. cleptric commented on Sep 2, 2025

    @cleptric
    Member

    I think this is ok, a limitation we can document.

  4. self-assigned this
    on Sep 18, 2025
  5. github-actions commented on Sep 22, 2025

    @github-actions
    Contributor

    A PR closing this issue has just been released 🚀

    This issue was referenced by PR #17700, which was included in the 10.13.0 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions