Relationships
#4223 Hot reload can keep an old local behavior registry and memoized bundle after external catalog indexing (1602; e459 regression passes)
Opened by nckrtl · 10/31/2026
Observed on Linux with Swamp 20261028.205235.0-sha.1602a617, using repo-local behaviors, a shared extension catalog, and serve --hot-reload --remote-only.
Minimal reproduction (disposable repository):
- Start serve with a repo-local behavior @example/reload-probe at version 1; describe it remotely (and warm its method bundle if testing dispatch).
- Edit its entry to version 2 and change a validator in an imported helper. Add a second local behavior.
- Run a separate local CLI model type description to index the edited source into the shared catalog.
- Send an acknowledged
swamp serve reload --server <loopback endpoint>request. Without running a workflow first, describe the original behavior remotely.
Expected: after successful reload, the existing serve process reports version 2 and future dispatches use the updated validator/bundle, including newly discovered behavior metadata. Actual on 1602a617: disk/indexed catalog have version 2, but the warm serve registry still reports version 1. In production, @nckrtl/tool-direct remained 2026.10.30.3 while disk/catalog were 2026.10.31.1; a subsequent dispatch failed the removed agent_sha256 validator before effects. The old worker-cached JS still declared the old version. We did not establish a cache-key collision or the exact production command that advanced the catalog.
Two full restarts were needed to recover observed stale registries on 2026-10-31, around 08:39Z and 09:43Z. No cache eviction or credential changes were required.
Source investigation: createBundleSourceFactory memoizes bundlePromise and checks sourceSnapshotChanged only during its construction. Catalog state advanced by a different CLI can differ from definitions applied by the warm serve process.
Current release follow-up: serve is now 20261031.063736.0-sha.e459d219. The exact isolated external-index/reload regression fails on 1602a617 and PASSES on e459d219, with the same serve PID throughout and no workflow run required. e459 includes the local-extension reconciliation change associated with PR3523. We have not reproduced this stale-after-successful-reload defect on e459. Please confirm coverage of warm memoized bundles and imported-helper changes, and whether this historical issue is fully resolved by that change.
Open
No activity in this phase yet.
Sign in to post a ripple.