Abort Signal Not Working with Next.js Edge Functions #50364
Comments
github-actions
bot
added
the
Runtime
|
maybe relevant (no solution yet) #48682 |
|
did you find a solution? |
|
based on #50804 downgrading version to |
turns out this only works for a local setup, vercel's production LB seems not propagate abort information to the api endpoint |
|
I am facing the similar problem also with nodejs runtime - abort listener on request.signal is not triggered. |
This was referenced Jun 20, 2023
kodiakhq bot
pushed a commit
that referenced
this issue
Jun 22, 2023
### What? This is an alternative to #51330, which only support aborting the response (doesn't support back-pressure). If the client cancels the request (HMR update, navigates to another page, etc), we'll be able to detect that and stop pulling data from the dev's `ReadableStream` response. ### Why? We want to allow API routes to stream data coming from another server (eg, AI services). The responses from these other servers can be long running and expensive. In the case the browser aborts the connection, it's critical that we stop streaming data as soon as possible. ### How? By checking whether `response.closed` is set during the `for await (…)` iteration, we're able to detect that the client has aborted the connection. Cleanup of the `ReadableStream` is handled implicitly by the async iterator when the loop ends. The one catch is our use of http-proxy for worker processes. It does not properly detect a client disconnecting (but does handle back-pressure). In order to fix that, I've manually added event listeners to detect the disconnect and cancel the proxied req/res pair. Re: [WEB-1185](https://linear.app/vercel/issue/WEB-1185) (we still need back-pressure) Fixes #50364 Fixes vercel/ai#90
|
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Verify canary release
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000 Binaries: Node: 18.15.0 npm: 9.5.0 Yarn: N/A pnpm: 7.18.2 Relevant packages: next: 13.4.4-canary.13 eslint-config-next: 13.4.4 react: 18.2.0 react-dom: 18.2.0 typescript: 5.0.4 warn - Latest canary version not detected, detected: "13.4.4-canary.13", newest: "13.4.4". Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue. Read more - https://nextjs.org/docs/messages/opening-an-issueWhich area(s) of Next.js are affected? (leave empty if unsure)
Middleware / Edge (API routes, runtime)
Link to the code that reproduces this issue or a replay of the bug
https://github.com/Fawwaz-2009/demo-abort-signal-not-working-in-edge-function
To Reproduce
Describe the Bug
when we use EventSource and fetch with AbortController. Simply put, the 'abort' event that's part of the request.signal in the edge function isn't firing like it should.
Expected Behavior
Normally, if a request gets cancelled from the client side, the 'abort' signal in the edge function should light up. This helps stop any work related to the request on the server-side, which is good for keeping things running smoothly.
Which browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response
The text was updated successfully, but these errors were encountered: