Upgrading from 1.0.1 to 1.0.2 results in requestContext.get('key') returning undefined

[potyl]

Hi,

After upgrading asynchronous-local-storage from 1.0.1 to 1.0.2 any call to requestContext.get('key') to return undefinded.

I was able to reproduce the issue with the following snippet:

import fastify from 'fastify';
import { fastifyRequestContextPlugin, requestContext } from 'fastify-request-context';

const ALS_KEY = 'my-key';

const server = fastify();

//    server.register(fastifyRequestContextPlugin);

server.addHook('onRequest', (req, reply, done) => {
    requestContext.set(ALS_KEY, { value: 42, });
    done();
});

server.get('/', async () => {
    const stored = requestContext.get(ALS_KEY);
    console.log(`stored = ${JSON.stringify(stored, null, 2)}`);
    return { status: 'ok?', got: stored };
});

server.listen(3000, (err, address) => {
    if (err) {
        console.error(err);
        process.exit(1);
    }
    console.log(`Server listening at ${address}`);
});

Note that this might be due to a wrong usage of the library that manifest itself after the upgrade.
I noticed that if I uncomment server.register(fastifyRequestContextPlugin); that the ALS then works as expected.

I have an app that doesn't register the plugin fastifyRequestContextPlugin and works fine when using requestContext in 1.0.1 but fails and always gets undefined once we upgrade to 1.0.2.

Do we need to register the plugin fastifyRequestContextPlugin ?
Is there a regression in 1.0.2 that we're hitting?

[kibertoad]

@potyl Can't put my finger immediately on why that would be working previously, but I don't understand your use-case either. Why are you trying to use a part of plugin without using plugin itself? Hooks generated by fastifyRequestContextPlugin are responsible for ensuring that correct context is preserved within correct request. Most likely you are hitting fastify/fastify-request-context#12 which fastify-request-context handles for you. If you want to consume requestContext directly, you would need to do the same context syncing that plugin does for you (see the PR linked).

[potyl]

@kibertoad the use-case is a simplification of what's happening on my application.

Thanks for pointing out the issue that we're hitting. I see that we're not using the plugin properly.

In my case I have a library that's agnostic to any web framework, the library is being used inside a fastify server but from the point of view of the library it doesn't require any dependency to fastify. The library does expose an "initialization" function that is expected to be used by a fastify app so that it can pass a context. That function uses a ALS to work.

Then later on during the development ALS was needed inside the actual fastify app and the plugin was used without registering it. Somehow it worked fine with 1.0.1 and only during the upgrade did we notice a strange behavior.

I will register the plugin for the bits in the fastify app that rely on requestContext.

[potyl]

Actually, ignore my last comment. I do see in the code that we are registering the plugin fastifyRequestContextPlugin.
Although the upgrade to 1.0.2 does break our fastify app as all calls to requestContext.get() now return undefined.

[potyl]

I see that if I upgrade fastify-request-context from 2.1.1 to 2.1.3 then asynchronous-local-storage will be upgraded too (from 1.0.1 to 1.0.2) and requestContext.get() is now working as expected!