Potential issue with long living http2 connections

[unilynx]

(I'm not ready to make an issue yet as my problem takes a long time to reproduce, so i'm checking to see if anyone has pointers where to look/what to try to isolate the issue)

I'm using node26.4 on mac with undici 8.5.0. I've built a backupscript that

• POSTs a message to a HTTP/2 server telling it has started to backup
• Runs the backup process. This can easily take 60 minutes
• POSTs a status report to the same server telling to indicate it has finished

This last POST always hangs. I've set a 90second abort on each attempt and retry 15 times, I'll just get 15 AbortErrors.

If I connect to the process during the POST hangs (kill -USR1, chrome devtools) I'll see any fetch() to the same server hang (whether POST or GET), but I can fetch other servers just fine. So I'm suspecting this has to do with unidici keeping connections open for reuse, and something timing out on either the server or the client making the connection unusable. Or perhaps it's NAT timing out the unused connection (I've tried from 2 different locations/behind 2 routers, both home and office). I can't pin it down yet.

Switching to a manually installed undici 8.7.0 seems to help a bit - now I'm at only 3 AbortErrors and the 4th retry succeeds, but it'll be a few more long testruns before I can be sure it actually makes a difference - maybe I just got lucky.

Any hints on how to further isolate this? Can I reset the persistent connections, or limit their duration, to see if that changes anything and. Any flag that might provide insight on what exactly happens on the HTTP2 layer?

[metcoder95]

I'd suggest to enable the ping interval and set it to regular timings; this will help the h2 connection be alive and not be terminated by either way.

In combination, extending the maxKeepAliveTimeout will allow negotiate longer lived connections with the server.

Can you provide a small
Minimum Reproducible Example?

[unilynx]

unfortunately I'm not close to having an easy reproduction

I do have some more leads, this time I saw

Fetch failed TypeError: fetch failed

[cause]: InformationalError: HTTP/2: "GOAWAY" frame received with code 0

I think this is nginx shutting down a persistent connection, and the POST request colliding with this.

Either undici or nginx isn't handling this nicely. https://trac.nginx.org/nginx/ticket/2224 suggests there is a two stage GOAWAY to do a nice shutdown, and even if undici properly implements that, it seems nginx has decided that they won't.

Maybe I should try to just do a dummy GET first just to absorb a broken connection, and see if the POSTs stop failing then

[metcoder95]

You can extend fetch with a RetryAgent that takes care of that; undici will re-queue failed requests due to GOAWAY but the actual initial request trigger will lead to a failure.

[pacocartones]

The GOAWAY with code 0 is a useful lead. Before trying to explain which side mishandles it, I would use one controlled experiment to separate stale-session reuse from the rest of the backup:

1. Run a baseline as today, but log the full error.cause, the timestamp of the last successful request, and the duration of the idle period.
2. In a second run, use a dedicated Agent as the dispatcher and replace it immediately before the final POST (closing the old one with agent.close()). If the fresh dispatcher consistently succeeds, that is strong evidence that reusing the existing HTTP/2 session is part of the trigger.
3. Repeat that comparison with a deliberate HTTP/2 PING cadence via h2Options.pingInterval, chosen below any relevant proxy idle timeout. Keep the interval as the only changed variable.

A dummy GET can be a useful probe too, but I would make it a separate variant: if it fails before the final POST, it turns the intermittent failure into an earlier observable signal rather than masking it. A minimal repro is still the ideal end state, but this matrix should make a long-running reproduction much more informative.

[pacocartones]

Following up on the MRE request — I built a local HTTP/2 lab to try to reproduce the failure, testing exactly the nginx behavior from trac.nginx.org/nginx/ticket/2224 (a single GOAWAY, no two-stage shutdown). Environment: Node v24.14.1, undici 8.5.0 (your version), 8.7.0 and 8.10.0, TLS with ALPN h2.

Scenarios tested, each on all three versions:

• A — GOAWAY(0) arrives while a request is in flight (stream ≤ lastStreamID, server finishes it normally)
• B — session goes idle, GOAWAY + socket destroy arrive during idle, then the session is reused
• C — GOAWAY + immediate socket destroy while a request is in flight
• D — nginx-style: single GOAWAY(0), socket stays open, new streams on the old session are silently ignored; then a new request is made
• E — refused in-flight stream: server answers a just-sent request (stream 3) with GOAWAY(0, lastStreamID=1) and never responds on it (per RFC 9113 §6.8 the client may safely retry stream 3)

Result: I could not make any of these hang or fail — on 8.5.0, 8.7.0 or 8.10.0. In-flight requests complete, refused streams are replayed on a fresh session (my server log shows new session #2 serving the replayed request), and reuse after an idle GOAWAY opens a new session transparently. So at least for single-GOAWAY races, undici's handling looks correct on the versions you tested.

That negative result is itself a clue: combined with your symptoms (hangs only after a ~60 min idle, from two different networks, and every request to that origin hanging — including fresh GETs — while other origins work), I'd now point less at GOAWAY handling and more at a silently dead connection: a NAT/conntrack entry (or a middlebox) expiring during the long idle window. The TCP connection then looks open on both ends but packets go nowhere — which produces exactly your pattern: requests that hang until your 90 s abort fires, with no error from the client itself. It would also explain why the version change to 8.7.0 only "helped a bit" (timing luck) rather than fixing it.

Two cheap experiments to confirm or kill this hypothesis:

1. Set h2Options: { pingInterval: 30000 } (or any value comfortably below your routers' idle timeout) on the Agent/Client. If the hangs disappear entirely, the keepalive is keeping the NAT path warm — hypothesis confirmed. Note this differs from a dead-connection detector: it prevents the middlebox state from expiring in the first place.
2. As a control, keep pingInterval off but reduce the idle window (e.g. keepAliveTimeout shorter than the NAT timeout, forcing fresh connections). Same prediction.

If even with a warm path you still see hangs, one more discriminator: at hang time, create a fresh Agent and try the same request through it. If the fresh dispatcher succeeds while the pooled one keeps hanging, the dead object is the pooled h2 session/socket itself (not the server, not DNS, not your process) — and that would be worth a proper issue with the repro details.