fix: a recreated module widget must invalidate the stale module

[maartenbreddels]

The bug

Hot reload of an ES module can permanently stop reaching the browser: the page keeps rendering the previous version of the module, forever.

Module.initialize() calls addModule() but never invalidateModule() — only the change:code/change:url/change:dependencies handler does. A freshly created widget can carry a name that is already in the page-global registry: solara closes the per-kernel module widgets on a hot reload (a trait update on a closed widget never reaches the browser) and creates new ones. The registry then still holds the previous, already-resolved module, so a consumer rendered after the reload resolves that one instantly — and nothing re-renders it when the new module is provided a moment later.

It is a race between the new widget's async load and the consumer's requestModule: module first → correct new version; consumer first → stale version, permanently.

Evidence

Reproduced with solara's esm_test.py::test_ipyreact_module_hot_reload in a Linux container limited to 1 CPU (the race is essentially never lost on an unloaded machine, which is why this only shows on busy CI runners):

ipyreact	result (3 runs, 150s budget each)
unpatched	2–3 runs stuck on the old version, ~157s each (never arrives)
this fix	3/3 correct version in 5.8–7.1s

The behaviour is bimodal — the new module arrives within seconds, or never — confirming it is a lost update rather than slowness.

The test

test_module_recreated_widget_hot_reload covers the recreate flow (render, close the module widget as context.restart() does, define again, render again). Note it needs CPU pressure to fail deterministically without the fix, so it documents the path rather than guarding it on a fast machine; the container comparison above is the real proof.

🤖 Generated with Claude Code