Devasia Thomas

@bnoordhuis i'll see if I can come up with something. Since this happened across multiple frameworks this should be reproducible by using just the core stuff. Gimme this weekend :)...

I understand the inevitable race that can happen and I agree you have to retry in such a scenario and its best that the application takes care of that. But...

@bnoordhuis So, I don't have guaranteed replicability - but over time (5 of the runs i got it in like the first 5 mins, 2 other runs i had to...

To surface the problem more frequently, i tried to randomly close ~ 1% of the connections after the response was ended so this ``` res.socket.requestInFlight = false; if(res.socket.closeAfterResponse) { ```...

> Haven't looked into this in depth but I think this is expected. There is a race condition in the http/1.1 spec for keep alive requests. This can be mostly...

> The client should not make any request on a connection that has been idle more than timeout duration (minus some threshold). @ronag , timeout is not the problem here....

> FYI, the TCP FIN, in nodejs spectrum, is the 'end' event of a socket. I don't see any code of http agent makes use of this event to decide...

> > Node.js Client sends ACK --> Idk what code path makes this happen, but this also causes socket to go to top of connection pool. Because the very next...

@ywave620 I just checked ``http.createServer`` call path real quick and it seems that the [Server](https://github.com/nodejs/node/blob/main/lib/_http_server.js#L512) creates a ``net.Server`` with halfOpen as true always. Please confirm. But my issue isn't with...

> I think your best bet is to either disable keep alive or switch to undici. You've mentioned this already. Neither of which I can do. However, I'm fairly certain...