You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
When running sentry.init with opentelemetry in next.js instrumentation, next.route span attributes is lost #15634
Run without commenting out the line(reproduce the problem) - pnpm dev
Comment out the line and run it (desired behavior) - pnpm dev
Running pnpm dev and build after that gives the same result.
Expected Result
next.route must remain in BaseServer.handleRequest span_type regardless of whether sentry.init is included in the code or not
Actual Result
Additional Details
I am using next.js and opentelemetry and prometheus together.
At this time, we are trying to add metrics to prometheus by utilizing next.route, an opentelemetry span element provided by next.js.
However, when running sentry.init in the instrumentation file like the sentry guide says, the next.route span element is lost in the BaseServer.handleRequest event logged in onEnd.
When sentry.init is excluded from the code, the next.route span element remains normally.
Why does the next.route span element disappear depending on whether sentry.init is present or not?
Not shown in the image, but other span elements also change depending on sentry.init being run.
You can easily reproduce this by cloning the above repository and running the project.
Hi, I looked into this a bit and can reproduce. I don't think we are stomping on the attribute directly. Instead what we're doing is hoisting spans above the BaseServer.handleRequest span and Next.js applies the next.route attribute to the "local root span"
Here are the attributes for the same req span before and after adding Sentry.
Before I begin, i would like to express my gratitude for quickly checking my issue and for the effort you put into maintaining this project.
I fully understand that it may not be possible to fix this issue immediately. Houwever, I hope this problem can be resolved as soon as possible.
Although it was unintentional, the interaction between various libraries may add new values, but it seems necessary to improve the situation where they interface with each other and affect the original data.
This is very important metric for monitoring the state and improving the performance of many applications at my current company.
While it is not an issue with Sentry or OpenTelemetry, if we cannot record query string or path parameters by pattern, the cardinality of data in the application memory will continuously increase, which may put a load on the application.
Of course, using regular expressions or specific path patterns can alleviate this to dome extent, but it is not easy for all developers in other teams to create it according to the requirements of the applications they are developing.
I would be very grateful if this could be improved. I hope this issue can be resolved, even if it takes time. Can you notify me when you start working on it?
Activity
rlawnsxo131 commentedon Mar 11, 2025
Link to issue that looks similar to this: #14660
lforst commentedon Mar 12, 2025
Hi, I looked into this a bit and can reproduce. I don't think we are stomping on the attribute directly. Instead what we're doing is hoisting spans above the
BaseServer.handleRequestspan and Next.js applies thenext.routeattribute to the "local root span"Here are the attributes for the same req span before and after adding Sentry.
Before:
After:
I am backlogging for now but also don't think we will fix this soon.
rlawnsxo131 commentedon Mar 13, 2025
@lforst
Hello!
Before I begin, i would like to express my gratitude for quickly checking my issue and for the effort you put into maintaining this project.
I fully understand that it may not be possible to fix this issue immediately. Houwever, I hope this problem can be resolved as soon as possible.
Although it was unintentional, the interaction between various libraries may add new values, but it seems necessary to improve the situation where they interface with each other and affect the original data.
This is very important metric for monitoring the state and improving the performance of many applications at my current company.
While it is not an issue with Sentry or OpenTelemetry, if we cannot record query string or path parameters by pattern, the cardinality of data in the application memory will continuously increase, which may put a load on the application.
Of course, using regular expressions or specific path patterns can alleviate this to dome extent, but it is not easy for all developers in other teams to create it according to the requirements of the applications they are developing.
I would be very grateful if this could be improved. I hope this issue can be resolved, even if it takes time. Can you notify me when you start working on it?
Once again, thank you for your hard work.
lforst commentedon Mar 13, 2025
Hi, I fear we wont be able to pick this up anytime soon. Feel free to contribute a fix to the SDK or Next.js itself!
github-actions commentedon May 19, 2025
A PR closing this issue has just been released 🚀
This issue was referenced by PR #16297, which was included in the 9.20.0 release.