connectrpc / connect-es

Describe the bug

The signal request.signal on a UniversalServerRequest is aborted as soon as the request body has been read, at least over HTTP/1.1. As a result, for most rpc handlers the request appears aborted before the handler begins (since the request has already been read). Ideally the signal would not be aborted until the underlying connection closes.

To Reproduce

Create an rpc handler using node HTTP/1.1, hit the endpoint with a POST request, and read request.signal.aborted at the top of the handler. It will appear aborted (i.e. take the value true) even though the client and server maintain a connection, and the client will be able to receive the response.

Environment (please complete the following information):

@connectrpc/connect-node version: on latest 1.3.0, likely going back further as well.
Node.js version: v16+

Additional context

The issue most likely goes back to this change in node v16 nodejs/node#40775, where the 'close' event on an IncomingMessage indicates that you've read the whole message, whereas in the past it represented the resource underlying the request (i.e. would not close until the request/response flow ended, either due to actions taken by the server or client). I believe the more straightforward fix may be to use the node response object's 'close' event rather than the request object's here:

connect-es/packages/connect-node/src/node-universal-handler.ts

Lines 120 to 121 in fa7726b

    
           nodeRequest.once("error", onH1Error); 
        
           nodeRequest.once("close", onH1Close);

Thank you for reporting and for finding the node issue! I can reproduce. Not sure if relying on the response is the solution here.

	nodeRequest.once("error", onH1Error);
	nodeRequest.once("close", onH1Close);

Requests appear aborted before handler over HTTP/1.1