-
Notifications
You must be signed in to change notification settings - Fork 225
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
Traverse context to find active span/transaction #1964
Conversation
💔 Tests Failed
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪Test errorsExpand to view the tests failures> Show only the first 10 test failures
|
@dgieselaar This looks pretty good! Thanks for this. I think we should pursue this. I also (eventually) want to get a sense of the possible performance impact here because the async hook functions are hot spots. My understanding improved when (locally) renaming |
@trentm I was thinking about the performance issue as well. I'll try to have a look at profiling next week, it's also going to be useful for me to learn more about the Kibana instrumentation performance overhead we discussed. Other than the perf issue I think I also not fully understand the consequences of this change. But it does feel like a step in the right direction. I hope to get back to this ~next week after I've had a look at the performance implications. |
For example, this handles the problem case from #1964
I believe this is fixed by #2181 |
(Keeping this in draft, as I expect this PR is mostly just suitable for discussion)
I'm running into an issue where if the active span for the current async context ends, and a new span immediately starts, the ended span is the parent of the new span.
This PR attempts to address this issue by:
This assumes that each transaction/span is executed in its own async context. If that's not the case, weird things might happen.