| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
This PR only has a change to the test. Is this sentence in error or is there a missing modified file that needs to be added? |
Sorry, something went wrong.
|
Yes, that sentence was wrong. I rewrote the commit message. PTAL |
Sorry, something went wrong.
|
The changes to the upgrade event handler looks good to me. I don't think we need the setTimeout() in the test setup. If you do want to force the data in two writes like that, maybe put it in a different test so we have one test that's straightforward and another test that's specific to the data definitely always arriving in two pieces? |
Sorry, something went wrong.
|
@Trott PR updated with your comments. Thanks |
Sorry, something went wrong.
|
LGTM if CI is happy. CI: https://ci.nodejs.org/job/node-test-commit/1664/ We need to get you onboarded so you can start these CI jobs yourself! Minor nit that can be ignored if you want: I don't think we need the gotData variable and check in the new test since we're guaranteeing the check of the value of recvData which can't possibly be set correctly unless gotData is true. But it doesn't hurt anything either, I guess. |
Sorry, something went wrong.
|
One other comment that you can ignore if you want: The same issue you're fixing here seems to afflict test-http-upgrade-client.js as well. Maybe fix that too, either here or in a separate PR? (I'm a fan of separate PR, but either way.) |
Sorry, something went wrong.
|
@Trott I've removed the gotData variable. |
Sorry, something went wrong.
|
Looks like the modified test fails (or is flaky?) on FreeBSD and Raspberry Pi: |
Sorry, something went wrong.
|
@Trott It seems the CI was started with the previous version of the PR: 8ac8915 (the one with gotData) and not the current one: santigimeno@d710d9c. Anyway, it's been helpful as it has shown that in those environments all the upgrade data was sent in only 1 chunk. I'll increase the timeout a little bit and maybe bring back the gotData variable as it has proven to be useful. What do you think? |
Sorry, something went wrong.
|
Nah, increasing the timeout won't work either as the client is closing the connection when it receives the upgrade request. I think I'm removing the test altogether as it may happen that the second write could fail due to a race condition with the client closing the connection. |
Sorry, something went wrong.
|
PR updated. I think this should work |
Sorry, something went wrong.
|
One nit, but LGTM if CI doesn't uncover anything. |
Sorry, something went wrong.
There was a problem hiding this comment.
Nit: As mscdex noted in the other PR that's similar to this, this callback might benefit from being wrapped in common.mustCall() to guarantee that it fires.
Sorry, something went wrong.
It's not guaranteed that the socket data is received in the same chunk as the upgrade response. Listen for the `data` event to make sure all the data is received.
|
PR updated. Thanks |
Sorry, something went wrong.
Sorry, something went wrong.
|
LGTM |
Sorry, something went wrong.
It's not guaranteed that the socket data is received in the same chunk as the upgrade response. Listen for the `data` event to make sure all the data is received. PR-URL: #4520 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
It's not guaranteed that the socket data is received in the same chunk as the upgrade response. Listen for the `data` event to make sure all the data is received. PR-URL: #4520 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
It's not guaranteed that the socket data is received in the same chunk as the upgrade response. Listen for the `data` event to make sure all the data is received. PR-URL: #4520 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
It's not guaranteed that the socket data is received in the same chunk as the upgrade response. Listen for the `data` event to make sure all the data is received. PR-URL: #4520 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
It's not guaranteed that the socket data is received in the same chunk as the upgrade response. Listen for the `data` event to make sure all the data is received. PR-URL: nodejs#4520 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
It's not guaranteed that the socket data is received in the same chunk as the upgrade response. Listen for the `data` event to make sure all the data is received. PR-URL: nodejs#4520 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
It's not guaranteed that the socket data is received in the same chunk as the upgrade response. Listen for the `data` event to make sure all the data is received. PR-URL: nodejs#4520 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
| Back | FazBrowse Home | New Git URL |
It's not guaranteed that the socket data is received in the same chunk
as the upgrade response. Listen for the data event to make sure all
the data is received. Modify the test so it does not pass without
applying this change.
I was getting this error from time to time on OS X:
assert.js:89 throw new assert.AssertionError({ ^ AssertionError: <Buffer > == 'nurtzo' at ClientRequest.<anonymous> (/Users/sgimeno/node/node/test/parallel/test-http-upgrade-agent.js:51:12) at emitThree (events.js:98:13) at ClientRequest.emit (events.js:176:7) at Socket.socketOnData (_http_client.js:342:11) at emitOne (events.js:78:13) at Socket.emit (events.js:170:7) at readableAddChunk (_stream_readable.js:146:16) at Socket.Readable.push (_stream_readable.js:110:10) at TCP.onread (net.js:523:20)