Skip to content

Rethink INP span traceId assignent #16231

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Lms24 opened this issue May 7, 2025 · 0 comments
Open

Rethink INP span traceId assignent #16231

Lms24 opened this issue May 7, 2025 · 0 comments

Comments

@Lms24
Copy link
Member

Lms24 commented May 7, 2025

Problem Statement

Today, we assign the currently active traceId to an INP standalone span when creating it. However, we backdate the INP span's startTime to the time of the actual interaction and also assign the active route span name of said interaction. This leads to a very weird trace view experience, where the INP span happens way before the actual trace root span (e.g. a navigation span).

Solution Brainstorm

We should rethink the traceId assignment to not only assign the root span name that was active at interaction time but also that span's traceId. This might however require us to do some virtual trace continuation shenanigans or add the possibility to explicitly pass in a traceId when starting a span. Things to consider:

  • INP emissions are not tied to times where a parent span exists. This is also a problem in the current implementation, where for such cases we fall back to the currently active route name
  • we need to ensure that retroactively adding the INP span to an "old" trace does not mess with previous trace linking
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant