Relationships
#3284 Remote worker keeps running stale code for an edited repo-local extension model
Opened by skunk-ape · 10/12/2026· Shipped 10/13/2026
Problem
A connected remote worker keeps running the old code of a repo-local extension model after the model's source is edited. The edit only reaches the worker after swamp serve and the worker are restarted with a fresh --cache-dir.
Repro
Seen on swamp 20261008.143625.0-sha.ee36b409, with one machine running both the server and the worker:
- Run
swamp initin a fresh repo. Add a model underextensions/models/(e.g.@stagetest/planner) whose method writes a resource, and create an instance of it. - Start
swamp serve --port 19090, mint a worker token, and connect a worker from another directory withswamp worker connect ws://127.0.0.1:19090 --token <t> --label role=worker --cache-dir <dir>. - Run a workflow whose steps are placed on the worker (
labels: { role: worker }) withswamp workflow run <wf> --server ws://127.0.0.1:19090. The step succeeds on the worker. - Edit the model's source so the method writes an extra field, then run the same workflow again.
Expected: the second run executes the edited code, as a local swamp model method run does.
Actual: the second run's records have the old shape. The edit took effect only after both processes were stopped and the worker reconnected with a new --cache-dir.
Notes
- This may be intended for pulled extensions (
trusted-pulledbundle reuse). For a model being developed in the repo it is surprising, and nothing says the worker is running stale code. - I have not checked whether restarting only the server, or only the worker, is enough.
- Found while testing a design for stagecraft (swamp-club #3274).
Shipped
Click a lifecycle step above to view its details.
stack72 commented 10/12/2026, 11:35:21 PM
Remote workers do get extension code from swamp serve, not their own filesystem. Each dispatch names a server-produced bundle by content fingerprint; the worker fetches it on a fingerprint cache miss and retains that immutable bundle. When the server produces changed bundle content, it emits a new fingerprint and the existing worker should fetch it automatically. A new --cache-dir should therefore not be needed.
The stale code in this repro is at the running swamp serve process: it loads repo-local extensions at startup and retains the resulting bundle for its lifetime. The existing --hot-reload path is for pulled extensions, not repo-local extension source edits. Restarting only serve should produce a fresh bundle/fingerprint; the same connected worker and cache directory should then use the edited code.
So the worker cache behavior is by design. The repo-local development reload behavior is the gap, and the report should be narrowed by confirming the server-only restart case.
Sign in to post a ripple.