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

Relationships

#1602 Extension bundle cache not invalidated when an imported sibling module changes (entry-file fingerprint only)

Opened by catjen · 8/11/2026

A model extension whose entry file imports sibling modules (extensions/models/azure-devops/work-item-checker.ts importing ./report.ts, ./impact.ts, etc.) does not get rebundled when only an imported module changes. The catalog fingerprint appears to cover the entry file alone, so the stale bundle keeps executing old code.

Repro (swamp 20260710.093422.0-sha.05ac9e7f, Windows 11):

  1. Have a local extension model at extensions/models/azure-devops/work-item-checker.ts that imports ./report.ts from the same directory.
  2. Run a workflow that executes the model; note the output.
  3. Edit only report.ts (change a rendered string).
  4. Run the workflow again.

Expected: the bundle is rebuilt and the output reflects the report.ts change.

Actual: the output still shows the old string. swamp doctor extensions --json reports all sources healthy (stateTag Indexed) with an unchanged fingerprint, and swamp doctor extensions --repair applies no operations. Deleting the compiled bundle file (.swamp/bundles//azure-devops/work-item-checker.js) does not help: the next doctor/run rewrites the stale bundle, apparently from the catalog DB blob keyed by the unchanged entry-file fingerprint.

Workarounds found:

  • make any content change to the entry file so its fingerprint changes, or
  • delete the bundle AND its catalog row, then rerun.

Suggested fix: fingerprint the whole module graph of the entry file (all local imports), or hash the bundled output's inputs, so an edit to any imported file invalidates the bundle.

02Bog Flow
OPENTRIAGEDIN PROGRESSCLOSED+ 1 MOREASSIGNED+ 8 MOREREVIEW

Closed

8/11/2026, 6:45:27 PM

No activity in this phase yet.

03Sludge Pulse
stack72 assigned stack728/11/2026, 5:16:43 PM
Editable. Press Enter to edit.

stack72 commented 8/11/2026, 6:45:25 PM

Hi @catjen, thanks for the detailed report.

The version string in your report references sha.05ac9e7f — this commit does not exist in the swamp-club/swamp repository, so this is a custom build that we don't support. We're unable to investigate or fix issues against unofficial builds, so we're closing this out.

If you can reproduce the issue on an official release of Swamp, please reopen and we're happy to take another look.

Just as a heads up — Swamp is licensed under the AGPLv3, so if you're building from a modified fork you'll want to make sure you're meeting the source-availability requirements in Sections 5, 6, and 13 of the license. Worth a read of COPYING-EXCEPTION too, as the extension licensing exception only covers unmodified official releases.

Also noting that Windows isn't on our immediate roadmap, but it is something we plan to come back to down the line. Please do let me know if there's something we can do to raise the priority of our Windows support.

Thanks,

Paul

Sign in to post a ripple.