-
Notifications
You must be signed in to change notification settings - Fork 572
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 aborting Streams #3754
fix aborting Streams #3754
Conversation
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.
This is missing a test and is replacing one issue for another. I will take a look in a few days.
I need a test case that doesn't use a third party endpoint to work on it. The case you provided doesn't abort in node or Deno, and I cannot test in browsers because of CSP. The correct fix, afaict, is to remove the previous listener if > 1 exists (such that 1 listener always exists) or to only add a listener if there are none. |
import * as http from "http"
const abortStream = async () => {
const abortController = new AbortController
const readStream = (await fetch("http://localhost", { signal: abortController.signal })).arrayBuffer()
abortController.abort()
console.log(await readStream)
}
http.createServer((request, response) => {
if (request.url?.[1]) {
response.setHeader("content-type", "text/html")
response.end(`<!doctypehtml>
<html>
<body>
<script>
(${abortStream})()
</script>
</body>
</html>
`)
} else {
response.end(new Uint8Array(20000))
}
}).listen(80, abortStream) |
Thank you! |
This relates to...
#1711
Rationale
The simple fix to the memory issue caused a worse issue. Common patterns that involve catching AbortErrors, such as retrying slow requests, silently fail if the signal unluckily happens to be aborted during the read. A proper fix to the memory issue will likely be more involved.
Changes
revert 49e33a8
Bug Fixes
Aborting a Stream doesn't throw.
Status