test: fix http-upgrade-agent flakiness

[santigimeno]

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)

[Trott]

Modify the test so it does not pass without applying this change.

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?

[santigimeno]

Yes, that sentence was wrong. I rewrote the commit message. PTAL

[Trott]

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?

[santigimeno]

@Trott PR updated with your comments. Thanks

[Trott]

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.

[Trott]

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.)

[santigimeno]

@Trott I've removed the gotData variable.
I'll fix the other test in a separate PR

[Trott]

Looks like the modified test fails (or is flaky?) on FreeBSD and Raspberry Pi:

• freebsd
• raspberry pi

[santigimeno]

@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?

[santigimeno]

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.

[santigimeno]

PR updated. I think this should work

[Trott]

One nit, but LGTM if CI doesn't uncover anything.

CI: https://ci.nodejs.org/job/node-test-pull-request/1180/

[Trott]

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.

[santigimeno]

PR updated. Thanks

[Trott]

LGTM.

CI: https://ci.nodejs.org/job/node-test-pull-request/1200/

[jasnell]

LGTM

[jasnell]

Landed in 6018fa1