Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
Assigneeskeeb

Relationships

#1903 doctor extensions --repair reports catalog orphans pruned but leaves them in place

Opened by catjen · 8/29/2026

Summary

swamp doctor extensions --repair lists catalog-orphan rows as pruned, reports a count that does not include them, and leaves them in the catalog. The next command that has to re-bundle the extension then dies on the dead path the rows still point at.

Version: 20260828.151601.0-sha.56803638, Windows 11.

What happened

A local (non-upstream) extension had two catalog rows whose source_path was a stale WSL-style path from an earlier session — /mnt/c/project/repos/<repo>/... — while the repo actually lives at C:\.... swamp doctor extensions reported them correctly:

⚠ Catalog orphans (source missing on disk)
  • /mnt/c/project/repos/<repo>/extensions/models/<model>.ts  [@local/<ext>] Indexed
  • /mnt/c/project/repos/<repo>/extensions/reports/<report>.ts  [@local/<ext>] Indexed

--repair --dry-run said it would prune four rows, naming those two explicitly:

Repair DRY RUN
  4 catalog row(s) to prune, 4 bundle file(s) to evict
  x [row] c:/project/repos/<repo>/extensions/models/<model>.ts
     Tombstoned row — no longer active
  x [row] /mnt/c/project/repos/<repo>/extensions/models/<model>.ts
     Source path does not exist on disk — stale row from a prior session
  ... (2 more)

--repair --yes then logged:

[INF] swamp·doctor·repair: Pruned 2 catalog row(s)
...
Repair APPLIED
  2 catalog row(s) pruned, 4 bundle file(s) evicted
  x [row] c:/project/repos/<repo>/extensions/models/<model>.ts
     Tombstoned row — no longer active
  x [row] /mnt/c/project/repos/<repo>/extensions/models/<model>.ts
     Source path does not exist on disk — stale row from a prior session
  ... (2 more)

Note the mismatch: the count says 2, the itemised list shows 4, and the "Catalog orphans" section printed in the same output still lists the two stale rows. Reading bundle_types directly afterwards confirms all four rows are still present — only the two tombstoned ones were actually removed.

Why it matters

While the source is unchanged, swamp serves the cached bundle and nothing shows. The moment the extension source changes there is no bundle for the new fingerprint, so recoverMissingBundle tries to re-bundle from the recorded source_path and gets:

The system cannot find the path specified. (os error 3): readfile
'/mnt/c/Project/repos/<repo>/extensions/models/<model>.ts'

Every command that loads the model fails, including a scheduled workflow run — which is how this was found. It bites on the next edit rather than the one that created the stale row, and --repair reporting success makes it look repaired.

Guess at the cause

#251's acceptance criterion is "rows whose lockfile entry is gone AND whose source files don't exist". These rows belong to a @local/ extension, which has no lockfile entry at all (swamp extension list reports no upstream extensions). It looks like the preview predicate and the apply predicate disagree: the preview selects on "source path missing", the apply additionally requires something local rows never satisfy, and the applied listing is printed from the preview set rather than from what was pruned.

Reproduction sketch

  1. Register a local extension, let it bundle.
  2. Rewrite its bundle_types.source_path to a path that does not exist.
  3. swamp doctor extensions --repair --yes — reports the row pruned.
  4. Read bundle_types: the row is still there.
  5. Edit the extension source; every command that loads it now fails with os error 3 on the dead path.

Expected

Either the row is actually pruned, or the output does not claim it was. The itemised "Repair APPLIED" list should reflect what was pruned, and the count and the list should agree.

Workaround

Delete .swamp/_extension_catalog.db* and run any swamp command to re-index from disk. That recovered it cleanly.

02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED+ 1 MOREASSIGNEDCLASSIFICATION

Open

8/29/2026, 7:37:54 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
keeb assigned keeb8/29/2026, 7:11:03 PM

Sign in to post a ripple.