Conversation
size-limit report 📦
|
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
On Vercel, a function can be suspended as soon as it sends the response, so buffered telemetry arrives late or never. When a response finishes, keep the function alive with `waitUntil` until the response closes and the request's root span ends (2 s max), then flush. Closes #24909 Co-authored-by: Claude <claude@anthropic.com>
05da2d0 to
50ac024
Compare
sergical
changed the title
| requestContext.waitUntil( | ||
| new Promise<void>(resolve => response.once('close', resolve)) | ||
| .then(() => rootSpan && waitForSpanEnd(client, rootSpan, ROOT_SPAN_END_TIMEOUT_MS)) | ||
| .then(() => client.flush(2000)), | ||
| ); |
There was a problem hiding this comment.
Bug: The code waits for response.once('close', ...) without a timeout, which can cause the Vercel function to hang if a client uses HTTP/1.1 keep-alive.
Severity: MEDIUM
Suggested Fix
Wrap the promise that waits for the response.close event with a timeout mechanism, for example by using Promise.race with a setTimeout. This will prevent the waitUntil task from hanging if the close event is not emitted promptly.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/node/src/sdk/vercel.ts#L44-L48
Potential issue: In `setupVercelKeepAlive`, the code waits for the `response.close`
event to resolve a promise within a `waitUntil` task. However, if an HTTP/1.1 client
connects to a Vercel function without sending a `Connection: close` header, the
connection may be kept alive. This would delay the `response.close` event from firing,
causing the `waitUntil` task to hang until a socket timeout. While other timeouts on
span waiting and flushing prevent an indefinite hang, the function's completion is
unnecessarily delayed, impacting performance.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 50ac024. Configure here.
| unsubscribe(); | ||
| resolve(); | ||
| }; | ||
| const timer = setTimeout(done, timeout); |
There was a problem hiding this comment.
Keep-alive timer is not unref'd
Low Severity
Flagged because the review guidelines require setTimeout in @sentry/node to call unref() or safeUnref(). The keep-alive timeout in waitForSpanEnd does neither, so a recording root span can pin a Node process for up to two seconds after the response closes when VERCEL is set.
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 50ac024. Configure here.
| const { response } = message as { response?: HttpServerResponse }; | ||
| const requestContext = ( | ||
| GLOBAL_OBJ as unknown as Record<symbol, { get?(): VercelRequestContext | undefined } | undefined> | ||
| )[Symbol.for('@vercel/request-context')]?.get?.(); |
There was a problem hiding this comment.
Untyped double-cast lacks comment
Low Severity
Flagged because the review guidelines require a comment on new as unknown as casts in SDK source. The @vercel/request-context lookup uses that double-cast with no explanation, even though nearby vercelWaitUntil already types the same global.
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 50ac024. Configure here.
This branch has not been deployed
1 participant
On Vercel, a function can be suspended as soon as it sends the response. Telemetry that is still buffered (spans, logs, metrics, errors) then arrives late or never.
When a response finishes,
@sentry/nodenow useswaitUntilto keep the function alive. It waits until the response closes and the request's root span ends (2 s max), then flushes. It works with or without tracing.Some frameworks end the root span shortly after the response closes, so the flush waits for it.
Tested with unit tests and an integration test that fails without the change, and confirmed on a Vercel deployment.
Closes #24909. Refs #23087.
Created with Claude Code