request.state occasionally null

[kenkouot]

Edited: We were originally experiencing this bug on 8.2.0 and now still in 8.4.0.
We noticed that a small volume of requests started throwing odd errors. We're using two plugins, crumb and hapi-i18next and those plugins will error out trying to access a property of request.state, which turns out to be null.

The volume of this error is pretty low, it affects <0.01% of requests for at a non-peak volume of 1.5k rpm. Any help would be greatly appreciated.

Sample error (note, example if with crumb but other plugins that check request.state) will also fail:

Stack trace
TypeError: Cannot read property 'crumb' of null
at generate (/usr/www/440/node_modules/crumb/lib/index.js:156:34)
at /usr/www/440/node_modules/crumb/lib/index.js:85:13
at /usr/www/440/node_modules/hapi/lib/handler.js:312:22
at iterate (/usr/www/440/node_modules/hapi/node_modules/items/lib/index.js:35:13)
at Object.exports.serial (/usr/www/440/node_modules/hapi/node_modules/items/lib/index.js:38:9)
at /usr/www/440/node_modules/hapi/lib/handler.js:307:15
at internals.Protect.run (/usr/www/440/node_modules/hapi/lib/protect.js:56:5)
at Object.exports.invoke (/usr/www/440/node_modules/hapi/lib/handler.js:305:22)
at /usr/www/440/node_modules/hapi/lib/request.js:318:32
at iterate (/usr/www/440/node_modules/hapi/node_modules/items/lib/index.js:35:13)
at done (/usr/www/440/node_modules/hapi/node_modules/items/lib/index.js:27:25)
at finish (/usr/www/440/node_modules/hapi/lib/protect.js:45:16)
at wrapped (/usr/www/440/node_modules/hapi/node_modules/hoek/lib/index.js:798:20)
at done (/usr/www/440/node_modules/hapi/node_modules/items/lib/index.js:30:25)
at Function.wrapped [as _next] (/usr/www/440/node_modules/hapi/node_modules/hoek/lib/index.js:798:20)
at Function.internals.continue (/usr/www/440/node_modules/hapi/lib/reply.js:102:10)

[kenkouot]

Related to: hapijs/crumb#50

[hueniverse]

I need to know where you are calling the crumb generate() method. request.state is set after onRequest is called, and any JSONP arguments are processed. If you try to access request.state (as crumb's generate() does) in onRequest or in an extension after JSONP error, it will be null because no state has been processed at that point.

[kenkouot]

Hey @hueniverse, thanks for the reply. We're actually letting crumb call generate automatically by omitting any value for autoGenerate in the crumb plugin options. The actual code is here: https://github.com/Wikia/mercury/blob/dev/server/app.ts#L45.

I've done some testing and specified a crumb skip function that skips crumb's flow if request.state is null, and the error simply cascades into another plugin, hapi-i18next (link to source line).

[kenkouot]

Both crumb and my hapi-i18next plugins utilize onPostAuth and onPreHandler extensions respectively. So you're saying those are inappropriate and causing the occasional races?

[hueniverse]

Do you have state.parse set to false anywhere? The flow is pretty simple and the only way that request.state is null is when you either disable cookie parsing or look for it too soon. onPostAuth and onPreHandler come after cookie parsing and should never have an issue unless you disable it somewhere.

[kenkouot]

No, in our route config we have a failAction set to log for state, but we are definitely not setting state.parse to false anywhere.

[hueniverse]

Any JSONP?

[kenkouot]

None of our route handlers implement JSONP either 😭

[hueniverse]

Is this still an issue? Any new insights?

[devinivy]

If the cookie header itself is malformed and your failAction is not 'error', you can indeed get a null state later in the request lifecycle. hapi sets request.state to whatever the statehood module hands it– here you can see null being passed-off: https://github.com/hapijs/statehood/blob/ad84fa183888dfff017fc8d6e9d0496127d7eafe/lib/index.js#L128-L132

[devinivy]

I'd just like to add that this behavior probably changed between hapi v7 and hapi v8 when statehood's ties to hapi were refactored. If it's really bugging you @kenkouot, I imagine that patching request.state in onPreAuth would be an acceptable thing to do– request.state is initialized to an empty object (that's what you'd get if there were no cookie header at all).

I'm not entirely sure if this null business is considered a bug or not, but it clearly can be confusing. I personally think it's nice to assume that request.state is an object, as the docs would indicate.

[hueniverse]

It is a bug. Thanks for digging into it. I'll take another look.