Thank you so much for your attention and contribution! We will arrange an internal review for this PR shortly, and all feedback will be shared right here in the discussion.

Thanks @dvd233 — lazy-loading "undici" looks like a good way to remove the SQLite-mode side effect.

I noticed one concurrency edge in the snapshot/restore guard:

const previousLegacy = g[LEGACY_GLOBAL_DISPATCHER];

undiciModulePromise = import("undici").then((mod) => {
if (
previousLegacy !== undefined &&
g[LEGACY_GLOBAL_DISPATCHER] !== previousLegacy
) {
g[LEGACY_GLOBAL_DISPATCHER] = previousLegacy;
}
return mod;
});

This assumes every change to the legacy slot while "import("undici")" is pending came from undici.

A possible interleaving is:

1. dispatcher A is installed;
2. "loadUndici()" snapshots A;
3. another subsystem intentionally installs dispatcher B;
4. the dynamic import resolves;
5. the guard sees "B !== A" and restores A.

So the fix can itself overwrite a newer process-wide networking decision.

Could restoration be conditional on proving that the current value is the compatibility dispatcher installed by this undici initialization, rather than restoring whenever the value merely changed?

I’d also add a regression where the legacy slot changes during the lazy import and assert that the newer value survives.

This is separate from #1157’s original bug: preserving the dispatcher present before undici initialization is correct; the question is ownership of a later concurrent change.

AI-assisted source review; I have not reproduced this with a real concurrent "setGlobalDispatcher()" + delayed module loader yet, so I’d treat it as a lifecycle/concurrency contract question rather than a confirmed production failure.

Thanks for flagging this. The existing follow-up commit 0ad1b09 addresses the interleaving: lazy loading now uses synchronous require(), so the dispatcher snapshot and restoration complete before another task can replace it. The cold-process regression starts the first HTTP request, installs a new dispatcher with setGlobalDispatcher(), and checks that the newer value survives.

The validation recorded for that update passed all 4 focused tests on Node 22.22.3. I have rechecked the current source and those existing results; I have not rerun the tests for this reply. The PR description retains the unrelated full-build limitation (missing scripts/seed-v2/tsconfig.json).