-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
DRAFT: Close Middleware Spans Early #1
base: honeycomb-otel
Are you sure you want to change the base?
Conversation
The url structure is `/v${versionNumber}/`, so these errors produce 404s
enforceInvariants() | ||
enforceInvariants(), | ||
// {% if honeycomb %} | ||
endSpan(mw), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The bug is that endSpan needs to be spliced after the mw, not before - but finishing this thought will require refactoring how it terminates at the router.
80fbaf6
to
1f8a01d
Compare
Since implementing this busted sketch, we learned that there's an alternate https://medium.com/aspecto/context-managment-in-opentelemetry-nodejs-e5cddf22a09e |
Eric suggested that it would be cool if we could close the middleware spans prior to the next middleware getting called. In other words, instead of
this:
This would make traces a lot more compact and give a better idea at a glance of how long the entry for the middleware takes. For exit, we could do another trace on the back, or assume that work is usually short-lived and emit a span event on exit instead.
As you can hopefully see from the diff, this is EXTREMELY hairy. What you won't see from the diff is that the tests currently fail - the test middleware's context gets added to the HTTP span, not the test middleware span. Alas!
I didn't want to push on this too far + instead focus on what we have now, but I thought it was a good idea and wanted to post my notes.