-
Notifications
You must be signed in to change notification settings - Fork 27.2k
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
Fix telemetry span duration for request spans #70908
base: canary
Are you sure you want to change the base?
Conversation
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
(span) => { | ||
if (span) { | ||
const res = args[1] | ||
res.end = new Proxy(res.end, { |
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.
Is there no res.on('end', ...)
?
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.
Correct me if I am wrong, but res.on('end') will not work on Vercel because the underlying lambdas freeze on res.end() which happens before res.on('end').
If that is not the case anymore it would be amazing because it would simplify the code here a lot.
…13904) Drop all spans/transactions emitted by Next.js for pages router API routes because they are currently super buggy with wrong timestamps. Fix pending: vercel/next.js#70908 This is just a bit of prep-work so we can at some point disable the logic where we turn on all Next.js spans and still have high quality data.
What?
Fixes a bug where telemetry spans for Pages Router requests are way too short.
Why?
The
handleRequestImpl
function is wrapped withtracer.trace()
to trace the duration of Next.js handling a request. Thetracer.trace()
function immediately starts a span and ends it when the return value of the passed callback resolves.In the pages router
handleRequestImpl
more or less immediately resolves, even though the request is still being processed. The started span is immediately ended, not waiting forres.end()
, which should be the actual end timestamp of the span.How?
I adjusted the
tracer.trace()
function to take an optionalmanualSpanEnd
option, which will make thetracer.trace()
function not end the span when the promise resolves. Additionally, we now manually end the request span with theonClose
hook.Relates to #64723