Crashes upon request on Node.js v15.5.0

[vsnthdev]

Support plan

• is this issue currently blocking your project? (yes/no): yes
• is this issue affecting a production system? (yes/no): no

Context

• node version: 15.5.0
• module version with issue: 20.0.3
• last module version without issue: N/A
• environment (e.g. node, browser, native): node
• used with (e.g. hapi application, another framework, standalone, ...): hapi application
• any other relevant information: N/A

What are you trying to achieve or the steps to reproduce?

Trying to start a Hapi.js server on node v15.5.0, using the following code from official docs 👇

import Hapi from '@hapi/hapi';

const server = Hapi.server({
    host: 'localhost',
    port: 8080
})

await server.start()
console.log(`Listening at ` + server.info.uri)

What was the result you got?

When a request is sent, the server crashes with the following message 👇

/Users/vasanth/Desktop/hapi-test/node_modules/@hapi/hapi/lib/request.js:497
            if (this.response.statusCode === 500 &&
                              ^

TypeError: Cannot read property 'statusCode' of null
    at Request._finalize (/Users/vasanth/Desktop/hapi-test/node_modules/@hapi/hapi/lib/request.js:497:31)
    at Request._reply (/Users/vasanth/Desktop/hapi-test/node_modules/@hapi/hapi/lib/request.js:434:18)
    at Request._execute (/Users/vasanth/Desktop/hapi-test/node_modules/@hapi/hapi/lib/request.js:280:14)
    at processTicksAndRejections (node:internal/process/task_queues:93:5)

What result did you expect?

The server to function normally and respond to requsets.

[vsnthdev]

Upon further inspection, I find that the server only crashes on Node.js v15.5.0 and perfectly on Node.js v15.4.0. Here is some additional information useful for more investigation on the issue 👇

Operating System: macOS Big Sur v11.1
Package Manager: Yarn v1.22.10
NPM Version: v7.3.0

[kanongil]

I can confirm that the hapi test suite fails on node v15.5.0 (also on Linux), with similar issues.

The only change that seems relevant, is the refactor in: nodejs/node#33035.

[cjihrig]

@kanongil beat me to it 😄. It's really annoying that all of these autoDestroy changes continue to break hapi.

[vsnthdev]

I really didn't believe it initially, but then the only change I made was to update to node v15.5.0, so a quick roll back of node revealed the issue.

[devinivy]

Thanks to Gil's correspondence on nodejs/node#33035 helping to illustrate the issue, this change in node is being reverted: nodejs/node#36647. I will try to keep an eye out for if node tries to re-land the original autoDestroy change in a non-breaking way. It does look like node is also adding a test that would have caught this, which is great: nodejs/node#36645. Once the reversion to node v15 is landed and published, I will close this issue after confirming hapi's test suite passes.

[mcollina]

Hi Folks, it would be great if Hapi to get into https://github.com/nodejs/citgm so that we can automatically spot regressions.

(FWIW this change is likely to make it in v16)

[kanongil]

@mcollina You should probably address your concerns towards the CITGM project instead given that there is a 5 year old open issue (nodejs/citgm#8) and a PR (nodejs/citgm#436).

[matthieusieben]

Having encountered this issue, and looked into its cause, I think you might want to re-consider flagging this as a bug.

The problem occurs on _special routes, when internals.drain is executed in the early stages of the life cycle. internals.drain will consume the req stream, which (in node 15.5) will cause both end and close events to be triggered directly (close being triggered in a "next tick").

This close event is then captured by internals.event (in request.js) that fails to detect that the lifecycle is "still ongoing", and that a close on req should not be considered as a failure at that point.

Because internals.drain will cause close to be triggered in the tick directly after end, this event occurs while the _lifecycle is still being processed.

In my humble opinion, request.js's internals.event should account for early close events, by doing something like (i didn't test but you get the idea):

    if (!request) {
        return;
    }

    // autoDestroy is enabled on the `req` stream, and the `req` stream was drained, this is basically the same as the "end" event
    // maybe request.raw.req._readableState.ended should be used instead?
    if (event === 'close' &&
        !request._isPayloadPending) {

        return;
    }

    request._isPayloadPending = false;

[devinivy]

@matthieusieben thanks for taking a close look, I see what you mean. Do you expect that this case can be triggered on node v12/v14? If there's a way to reproduce a bug then I will open a new issue for it, since this issue is now effectively tracking whether node v15 is patched. Either way I will spend some time with the info you provided above, and re-trace your steps in debugging.