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

#310 extension source rm leaves stale @local/. rows in catalog, blocking later pulls of registry types

Opened by bixu · 5/10/2026· Shipped 5/10/2026

Summary

swamp extension source rm <path> reports success and swamp extension source list shows 0 sources, but the source's contributed types remain in _extension_catalog.db (bundle_types table) tagged as @local/.<repo-basename>@0.0.0. On the next swamp extension pull <X>, swamp's resolver re-discovers those stale rows and refuses to install when the pulled extension's type collides — failing the pull and rolling back the filesystem changes.

Steps to reproduce

  1. swamp init a fresh repo at ~/.demo.
  2. swamp extension source add /path/to/local-checkout --repo-dir ~/.demo where the checkout contains a model that claims type @hivemq/mudroom (or any registry-published type).
  3. swamp extension source rm /path/to/local-checkout --repo-dir ~/.demo — CLI prints "Removed extension source" / "0 sources configured".
  4. swamp extension source list --repo-dir ~/.demo — confirms "No extension sources configured."
  5. swamp extension pull @hivemq/mudroom --repo-dir ~/.demo.

Expected

Pull succeeds — the only source contributing the conflicting type was just removed.

Actual

FTL error Error: 'Type "@hivemq/mudroom" (kind=model) is already claimed by
@hivemq/[email protected] at /Users/.../.demo/.swamp/pulled-extensions/@hivemq/mudroom/models/mudroom/mudroom.ts.
Cannot install @local/[email protected] at /path/to/local-checkout/extensions/models/mudroom/mudroom.ts —
filesystem changes rolled back.
Run `swamp extension rm @hivemq/mudroom` first if you intended to replace it.'

The suggested remediation (swamp extension rm @hivemq/mudroom) then errors with "Extension @hivemq/mudroom is not installed." because the rolled-back pull never registered it. The user is stuck.

Diagnosis

bundle_types retains rows for every type the removed source contributed, with extension_name = '@local/.<basename>' and source_path pointing into the removed source dir. In my repro, 13 rows persisted across source rm. The pull's atomic resolve picks them up as still-active local types.

Workaround

Surgical SQL on the catalog DB:

sqlite3 ~/.demo/.swamp/_extension_catalog.db \
  "DELETE FROM bundle_types WHERE extension_name = '@local/.<basename>';"

Then re-run swamp extension pull — succeeds.

Suggested fix

Have swamp extension source rm <path> purge bundle_types rows whose source_path is under <path> (DELETE FROM bundle_types WHERE source_path LIKE ? || '/%' OR source_path = ?) inside the same transaction that updates .swamp-sources.yaml. Optionally surface a misleading-error fix in the resolver: if the conflicting @local/.X rows don't correspond to any currently-registered source, drop them from the resolution set instead of rolling back.

Environment

  • swamp CLI: 20260509.235714.0-sha.7ace6b02
  • macOS 25.4.0 (Darwin arm64)
  • Repo affected: ~/.mudroom (custom MUDROOM_HOME), previously had /Users/.../hivemq/swamp-extensions registered as a source then removed.
  • Catalog state at time of failure: 14 rows in bundle_types (1 valid @bixu/mudroom, 13 stale @local/.mudroom).
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 3 MOREPR_MERGEDSHIPPED

Shipped

5/10/2026, 9:46:48 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack725/10/2026, 8:48:18 PM

Sign in to post a ripple.