You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cannot set property 'parsingHeadersStart' of undefined on 10.15.2 #26366
Out of the blue all of my build servers started to crash today. Each time a request comes in we receive the following error.
Node crashes.
TypeError: Cannot set property 'parsingHeadersStart' of undefined
2019-02-28T22:47:11.137079+00:00 app[web.1]: at IncomingMessage.resetHeadersTimeoutOnReqEnd (_http_server.js:744:32)
2019-02-28T22:47:11.137082+00:00 app[web.1]: at IncomingMessage.emit (events.js:194:15)
2019-02-28T22:47:11.137085+00:00 app[web.1]: at IncomingMessage.EventEmitter.emit (domain.js:441:20)
2019-02-28T22:47:11.137087+00:00 app[web.1]: at endReadableNT (_stream_readable.js:1103:12)
2019-02-28T22:47:11.137089+00:00 app[web.1]: at process._tickCallback (internal/process/next_tick.js:63:19)
This is related to version 10.15.2.
After rolling back to 10.15.1 we do not have any more issues.
I've tried to repro this locally and cannot. 😕
This happens on both of our Heroku environments however (prod and test).
The steps to repro it there for us was simply to deploy then send a request. It did not matter which request. We got this error every time. By simply reverting to 10.15.1 we were able to get our production server back up and running.
We deployed the code the was running successfully the previous day and it still failed. The only factor was the new release.
Is there anything else that I might be able to provide as insight?
2019-03-05 14:52:21,167 ERROR 20840 nodejs.TypeError: Cannot set property 'parsingHeadersStart' of undefined (uncaughtException throw 1 times on pid:20840)
at IncomingMessage.resetHeadersTimeoutOnReqEnd (_http_server.js:728:32)
at emitNone (events.js:106:13)
at IncomingMessage.emit (events.js:208:7)
at endReadableNT (_stream_readable.js:1064:12)
at _combinedTickCallback (internal/process/next_tick.js:139:11)
at process._tickCallback (internal/process/next_tick.js:181:9)
pid: 20840
hostname: hyj1991.local
Activity
rvagg commentedon Feb 28, 2019
@mcollina @nodejs/http
mcollina commentedon Feb 28, 2019
I’ll send a PR in tomorrow morning.
mcollina commentedon Feb 28, 2019
Can you please include a repro if you can?
mcollina commentedon Mar 1, 2019
I've investigated this issue, and I cannot understand when this can happen: we are only setting the
parsertonull. Protecting this is easy to do:node/lib/_http_server.js
Line 758 in fedc31b
undefined. However I don't understand in what conditions it can beundefinedand write a specific unit test.mcollina commentedon Mar 1, 2019
@rvagg @sam-github @jasnell @addaleax @apapirovski @mscdex do you have any idea?
jasnell commentedon Mar 1, 2019
Without a repro, no I have no idea
sam-github commentedon Mar 1, 2019
No idea, either 😕
bjjenson commentedon Mar 1, 2019
I've tried to repro this locally and cannot. 😕
This happens on both of our Heroku environments however (prod and test).
The steps to repro it there for us was simply to deploy then send a request. It did not matter which request. We got this error every time. By simply reverting to 10.15.1 we were able to get our production server back up and running.
We deployed the code the was running successfully the previous day and it still failed. The only factor was the new release.
Is there anything else that I might be able to provide as insight?
mcollina commentedon Mar 1, 2019
Are you using any framework? Which ones?
Can you run Node with
NODE_DEBUG=httpand include a few ~100 lines before the error? It might give us a clue.jmorrell commentedon Mar 1, 2019
@bjjenson On Heroku, you can do this by running
heroku config:set NODE_DEBUG=http -a $APP. I would suggest doing this in a staging environment.jasine commentedon Mar 2, 2019
same issue in docker containers
mcollina commentedon Mar 2, 2019
@jasine can you provide a repro for this? Even the output of a run with
NODE_DEBUG=httpmight be enough, or at least help.jasine commentedon Mar 2, 2019
@mcollina run with
NODE_DEBUG=httpTrott commentedon Mar 2, 2019
Code to reproduce:
4 remaining items
wyqsess commentedon Mar 5, 2019
i have the same issue too when try to connect in socket.io
version:
"socket.io": "^2.1.0"
"socket.io-client": "^2.1.1",
And i find that it will work well at node@8.15.0, and crash at node@8.15.1
hyj1991 commentedon Mar 5, 2019
@mcollina Same issue.
Here is a repro with egg.js: egg-socket.io-error-demo
Node version: v8.15.1 (and v8.15.0 is well...)
Error message:
fix: revert alinode to 3.14.0
fix: revert alinode to 3.14.0 (#44)
http: check for existance in resetHeadersTimeoutOnReqEnd
mcollina commentedon Mar 6, 2019
#26402 fixes it @hyj1991.
http: check for existance in resetHeadersTimeoutOnReqEnd
lpinca commentedon Mar 7, 2019
@hyj1991
The problem is that
request.socketis replaced by egg-socket.io with the socket.ioSocket. See https://github.com/eggjs/egg-socket.io/blob/9e7f71d835930d3a63c69635488737066f779661/lib/connectionMiddlewareInit.js#L8-L9.This is not ok and can break again in future.
http: check for existance in resetHeadersTimeoutOnReqEnd
http: check for existance in resetHeadersTimeoutOnReqEnd
http: check for existance in resetHeadersTimeoutOnReqEnd
http: check for existance in resetHeadersTimeoutOnReqEnd
snail-boy commentedon Jan 1, 2020
i have a idea , client 不要用socket-client 换成egg-socket.io 可以
Updated modules to fix nodejs/node#26366