Since Node.js 24.20 (nodejs/node#64847) the ClientRequest end() callback
fires with the connection error after the request has already emitted
error and been destroyed. That late ERR_SOCKET_CLOSED_BEFORE_CONNECTION was
forwarded to _final, destroying the stream and cancelling the retry that the
error handler had scheduled, so ECONNREFUSED was no longer retried and the
generic error surfaced instead of the real one.
Ignore the end() callback error once the request is destroyed; the real
error already drives the retry state machine. Write errors like EPIPE that
arrive while the request is still alive keep reaching the retry classifier.
Fixes#2469
The numeric Retry-After branch multiplied the header value by 1000 without
guarding non-positive results, so `Retry-After: 0` produced a falsy delay
that fell through to exponential backoff instead of retrying immediately.
The RFC-1123 date branch already clamps non-positive values to 1ms; mirror
that guard in the numeric branch so a non-positive Retry-After retries at
once.
dualfroz
upstream