8000 Cloned requests loose abort signal on GC · Issue #4068 · nodejs/undici · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
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

Jump to bottom

Cloned requests loose abort signal on GC #4068

Open
andreas-karlsson opened this issue Feb 27, 2025 · 2 comments
Open

Cloned requests loose abort signal on GC #4068

andreas-karlsson opened this issue Feb 27, 2025 · 2 comments
Labels
bug Something isn't working

Comments

@andreas-karlsson
Copy link

Bug Description

We noticed that AbortSignal.timeout() stopped working in our library with longer timeouts (in our case around 9s). Debugging showed that cloned (or constructor copied) requests won't respect an abort signal if GC has happened in between.

Reproducible By

Run with node --expose-gc

import { createServer } from 'node:http';

createServer(() => {
  // server that just hangs
}).listen(3000);

const ac = new AbortController();

let req = new Request('http://localhost:3000', {
  signal: ac.signal,
});

// cloned or copied requests (req = new Request(req)) breaks abort after gc
req = req.clone();

setTimeout(() => {
  // comment out the gc to make abort work
  global.gc();
  ac.abort();
  console.log('aborted, expecting immediate exception from fetch...');
});

await fetch(req);

Commenting out the cloning and/or the gc will make the code work as expected, i.e. the fetch call rejecting after abort.

Expected Behavior

A cloned request should respect it's abort signal even after a long time (or garbage collection).

Environment

macOS 15.3.1 (arm64), Node v23.4.0, v22.14.0, v20.18.0

Additional context

Debugging found that the difference before/after gc is that the "dependentControllerMap" entry for the signal is missing here
@andreas-karlsson andreas-karlsson added the bug Something isn't working label Feb 27, 2025
@KhafraDev
Copy link
Member

Debugging found that the difference before/after gc is that the "dependentControllerMap" entry for the signal is missing here

This looks familiar to another issue with fetch/signals caused by the AbortSignal implementation in node core but I couldn't find the issue. Should this be posted in node core instead? Is there anything we can do to fix this in undici?

@andreas-karlsson andreas-karlsson mentioned this issue Feb 28, 2025
Open
@andreas-karlsson
Copy link
Author

@KhafraDev I haven't managed to reproduce without Request involved. Also holding on strongly to the original request doesn't help. To me it seems odd that this could be a pure AbortSignal problem? Ah, or maybe you're saying that there can be a bug in the internal api of AbortSignal (like dependentControllerMap), but undici is using the api correctly..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@andreas-karlsson @KhafraDev
0