Can we fast-track this one? It just adds an assertion to a test.

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

Looks like tests are flaky. As far as I can see, failed tests are not related with this PR.

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

@puzpuzpuz something went wrong in CI, I restarted it

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

There's actually a deeper issue than that.

'use strict';
require('../common');
const assert = require('assert');
const { AsyncLocalStorage } = require('async_hooks');

const asyncLocalStorage = new AsyncLocalStorage();
const store = {};

asyncLocalStorage.runSyncAndReturn(store, () => {
  process.nextTick(() => {
    // This will fail because the second `runSyncAndReturn` re-enabled the storage
    // between when it was disabled and when the `nextTick` callback runs.
    assert.strictEqual(asyncLocalStorage.getStore(), undefined);
  });
  asyncLocalStorage.disable();
});

asyncLocalStorage.runSyncAndReturn(store, () => {
    assert.strictEqual(asyncLocalStorage.getStore(), store);
});

In this example, they are in the same sync tick, but imagine two runs from two separate http requests with a less immediate async task like a fs.readFile(...). The first request does its run*(...) call, ending with disabling the storage. The next does a run*(...) call, re-enabling it. Then the fs.readFile(...) from the first request runs its callback in the context again because it was re-enabled by the second request. This is very strange and unexpected behaviour--the disable should persist.

@Qard

There's actually a deeper issue than that.

Your snippet shows expected behavior which is described in the doc: https://github.com/nodejs/node/blob/311e12b96201c01d6c66c800d8cfc59ebf9bc4ae/doc/api/async_hooks.md#asynclocalstoragedisable

This behavior (and the general approach for .disable() method) was discussed in #26540. At a certain degree, I agree with you and I'd prefer to have a terminal (non-reversible) action for such method, but the consensus was to go with the current approach.

In any case, this discussion seems to be unrelated with changes from this PR and should be moved into a GH issue or a separate PR. WDYT?

Ah, hmm...okay. I must have missed that. Seems like very strange behaviour to me though. It makes it impossible to actually fully disable the storage. 😕

Anyway, yes, we can take this concern elsewhere.

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

Another flaky CI run 😢. Could someone re-run it?

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

I have rebased over the latest master. Maybe those flaky tests are fixed and it would help CI build to pass.

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

Landed in 68e36ad

v12 backport: #32318