-
Notifications
You must be signed in to change notification settings - Fork 83
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.
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
Requests appear aborted before handler over HTTP/1.1 #1025
Comments
Thank you for reporting and for finding the node issue! I can reproduce. Not sure if relying on the response is the solution here. |
Accidentally I reported this on Slack without seeing this bug first. In case it helps, I can provide additional details on my repro: Node v22.4.1 Can confirm that when adding It indeed appears to be related to the 'close' event being handled prematurely:
The abort controller
|
I also just ran into this issue when switching a service from http2 to http. My logger includes whether or not a response was aborted. It was very confusing and concerning to see that all of our requests were now being aborted. It also broke logic in our code that uses the abort signal. This is quite a significant bug. It effectively eliminates http1 as an option for any moderately complex Connect server. |
@srikrsna-buf, can you still reproduce this after #1206? |
Describe the bug
The signal
request.signal
on aUniversalServerRequest
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 valuetrue
) 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):
1.3.0
, likely going back further as well.Additional context
The issue most likely goes back to this change in node v16 nodejs/node#40775, where the
'close'
event on anIncomingMessage
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
The text was updated successfully, but these errors were encountered: