Summary
Two HMR correctness boundaries surfaced in concurrent hot-case coverage:
- Web/worker hot cases currently share the process console. Cases that
temporarily replace console.warn can capture warnings from a neighboring
concurrent case, producing duplicate disposed-module warnings and flaky
assertions.
- A removed module factory can be re-required during a
preserveDisposedModuleFactories apply transaction. That creates a fresh
cached module which is unlinked/deleted at finalization but remains
hot.active. A retained closure can then require a child after idle and
silently reattach the removed parent instead of producing the expected
disposed-module warning.
The worker matrix reproduced the first problem consistently as an extra
from disposed warning on different worker targets depending on scheduling.
The second problem is discriminated by retaining a closure created during the
apply callback, calling it after NEXT_HMR, and checking that the removed
parent is not reattached.
Proposed boundary
PR #14772 gives each WebRunner an inheriting scoped console, restores warning
hooks in finally, and adds a deterministic two-runner isolation regression.
The runtime finalizer marks a transient re-instantiated module inactive before
unlink/cache deletion; the hot fixture checks its post-idle disposed warning
and parent/child graph integrity across node, web, and worker runtimes.
The runtime change is limited to the existing preserve transaction and adds
no additional option or change to normal HMR disposal.
Summary
Two HMR correctness boundaries surfaced in concurrent hot-case coverage:
temporarily replace
console.warncan capture warnings from a neighboringconcurrent case, producing duplicate disposed-module warnings and flaky
assertions.
preserveDisposedModuleFactoriesapply transaction. That creates a freshcached module which is unlinked/deleted at finalization but remains
hot.active. A retained closure can then require a child after idle andsilently reattach the removed parent instead of producing the expected
disposed-module warning.
The worker matrix reproduced the first problem consistently as an extra
from disposedwarning on different worker targets depending on scheduling.The second problem is discriminated by retaining a closure created during the
apply callback, calling it after
NEXT_HMR, and checking that the removedparent is not reattached.
Proposed boundary
PR #14772 gives each
WebRunneran inheriting scoped console, restores warninghooks in
finally, and adds a deterministic two-runner isolation regression.The runtime finalizer marks a transient re-instantiated module inactive before
unlink/cache deletion; the hot fixture checks its post-idle disposed warning
and parent/child graph integrity across node, web, and worker runtimes.
The runtime change is limited to the existing preserve transaction and adds
no additional option or change to normal HMR disposal.