Skip to content
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.

Sign up for GitHub

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: post request signal #3354

Merged
merged 1 commit into from
Jun 22, 2024
Merged

fix: post request signal #3354

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions lib/api/api-request.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -154,6 +154,11 @@ class RequestHandler extends AsyncResource {
}

onComplete (trailers) {
if (this.removeAbortListener) {
this.removeAbortListener()
this.removeAbortListener = null
}

util.parseHeaders(trailers, this.trailers)
this.res.push(null)
}
Expand Down
25 changes: 23 additions & 2 deletions test/request-signal.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,9 +36,11 @@ test('post abort signal', async (t) => {

server.listen(0, async () => {
const ac = new AbortController()
const ures = await request(`http://0.0.0.0:${server.address().port}`, { signal: ac.signal })
const uresPromise = request(`http://0.0.0.0:${server.address().port}`, { signal: ac.signal })
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ this test was wrong because request api terminates when the stream has been completely consumed, so the connection has been closed. If we postpone the await we can throw the abort before dispatch starts consuming the stream, so the request is actually aborted

ac.abort()

try {
const ures = await uresPromise
/* eslint-disable-next-line no-unused-vars */
for await (const chunk of ures.body) {
// Do nothing...
Expand All @@ -61,9 +63,11 @@ test('post abort signal w/ reason', async (t) => {
server.listen(0, async () => {
const ac = new AbortController()
const _err = new Error()
const ures = await request(`http://0.0.0.0:${server.address().port}`, { signal: ac.signal })
const uresPromise = request(`http://0.0.0.0:${server.address().port}`, { signal: ac.signal })
ac.abort(_err)

try {
const ures = await uresPromise
/* eslint-disable-next-line no-unused-vars */
for await (const chunk of ures.body) {
// Do nothing...
Expand All @@ -74,3 +78,20 @@ test('post abort signal w/ reason', async (t) => {
})
await t.completed
})

test('post abort signal after request completed', async (t) => {
t = tspl(t, { plan: 1 })

const server = createServer((req, res) => {
res.end('asd')
})
after(() => server.close())

server.listen(0, async () => {
const ac = new AbortController()
const ures = await request(`http://0.0.0.0:${server.address().port}`, { signal: ac.signal })
ac.abort()
t.equal(await ures.body.text(), 'asd')
Comment on lines +92 to +94
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ in this case the abort signal is ignored since the request is completed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these are modeled after the fetch body mixins, I'm wondering if they should throw. In the fetch spec, if a request was aborted and you attempt to read the body, it'll throw an error. @ronag wdyt?

})
await t.completed
})
Loading