Skip to main content
← Back to list
01Issue
BugShippedSwamp CLI
Assigneesstack72

Relationships

#869 Local model source edit may not change the bundle cache key — rebuilt bundle shadowed by an older same-hash copy on a shared S3 datastore

Opened by mgreten · 6/27/2026· Shipped 6/29/2026

Thanks again for all the datastore work lately. I hit something while iterating on a local extension model and wanted to share it gently — I'm not certain I've got the mechanism exactly right, so please treat this as a hypothesis from one user's observations rather than a confident bug report.

What I observed

I edited a local model under extensions/models/ (added a method, bumped the version string in export const model). After the edit, the new method never became callable — swamp model method run <m> <newMethod> kept returning "Unknown method", and swamp model type describe showed the old method set.

Digging in, it looks like the bundle cache key didn't change when the source did:

  • swamp model evaluate doesn't seem to recompile the bundle — it logs "No expressions to evaluate" and rewrites only the (thin) evaluated definition, whose methods: {} is empty; the methods appear to come from the compiled bundle, resolved by typeVersion.
  • swamp doctor extensions does recompile local models (I saw "Bundled … / Wrote bundle cache" with a new byte count), so the bundler itself works.
  • But the rebuilt bundle was written under the same hash directory as before (e.g. bundles/<hash>/<model>.js), while the remote S3 copy at that hash still held the old bytes. Because the datastore pull restores the S3 copy, every method run ended up with the stale bundle again — so the edit never "stuck".

If I'm reading it right, the bundle hash may not be derived from the method-body source content (a version bump + ~40 added lines kept the same hash). If so, two different bundle contents can collide on one cache key, and on a shared S3 datastore the older copy wins.

How I worked around it

I let doctor extensions rebuild the local bundle, then manually overwrote the S3 object at that hash with the fresh local bundle and updated its index entry's size/mtime so they matched. After a pull, the new method registered and survived subsequent runs. That's clearly a hack — I mention it only to confirm the diagnosis (content vs. cache-key mismatch), not as a suggested fix.

What might help (deferring entirely to your judgment)

Would it make sense for the bundle cache key to incorporate the compiled source content (or the model version) so an edit always produces a distinct bundle? Or for the loader to prefer a freshly-rebuilt local bundle over a same-hash remote copy? I don't have a strong view on the right layer — just flagging that today a local source edit can be silently shadowed by an older same-hash bundle, which is a tricky thing to debug.

No urgency, and I'm very happy to be corrected if I've misdiagnosed it. Glad to share exact repro steps, the before/after bundles, or logs whenever useful.

Environment

  • swamp 20260626.202321.0-sha.1bf46b4f
  • @swamp/s3-datastore (MinIO backend), namespace agentic-tooling
  • Local model under extensions/models/ (not a pulled/published extension)

Possibly related: #867 (index/S3 reconciliation on pull).

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 5 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

6/29/2026, 2:25:46 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack726/29/2026, 10:46:58 AM
Editable. Press Enter to edit.

stack72 commented 6/29/2026, 2:25:55 PM

Thanks @mgreten for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.