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

Relationships

#1065 Self-update changes catalog source naming; stale rows trip I-Repo-1 and brick every CLI command

Opened by catjen · 7/10/2026· Shipped 7/10/2026

Description

After swamp self-updated (build 20260710.093422.0), the first extension-catalog reconcile that had something new to save failed an I-Repo-1 integrity assertion and ROLLED BACK - and because reconcile runs during CLI startup (configureExtensionLoaders), EVERY swamp command then failed with the same error. The CLI is fully bricked for the repo until the catalog db is deleted by hand.

The stale catalog rows were written by the previous build under source name @local/<repo-name> with lowercase forward-slash paths (c:/project/repos/<repo>/...); the new build scans the same repo as source @ with original-casing backslash paths (C:\Project\repos\<Repo>\...). assertIRepo1 sees every type "claimed by both" sources and aborts.

"error": "I-Repo-1 violation: type \"@nordictrustee/<model>\" (kind=model) claimed by both @ at C:\\...\\extensions\\models\\<model>\\<model>.ts and @local/<repo-name>@0.0.0 at c:/.../extensions/models/<model>/<model>.ts. ROLLBACK applied."
    at ExtensionRepository.assertIRepo1 (extension_repository.ts:595)
    at ReconcileFromDiskService.execute (reconcile_from_disk_service.ts:187)
    at configureExtensionLoaders (cli/mod.ts:381)

Steps to reproduce

  1. A repo with local extension models, catalog populated by an older build (rows show source @local/<repo>@0.0.0, lowercase paths).
  2. Self-update to build 20260710.093422.0 (source naming/path normalization changed to @ + original casing).
  3. Commands keep working UNTIL a reconcile needs to save (e.g. add a new extension file under extensions/models/).
  4. From then on every command - including swamp doctor extensions --repair - fails at startup with the I-Repo-1 error.

Expected

Reconcile treats rows for the same repo/source under the old naming as the same source (migrate or replace them), or the catalog is rebuilt on version change. A startup integrity failure should also not brick unrelated commands (doctor --repair should be reachable to fix exactly this).

Actual

Permanent startup failure. Workaround: delete .swamp/_extension_catalog.db (+ -shm/-wal) and let reconcile rebuild - clean afterwards.

Environment

swamp 20260710.093422.0-sha.05ac9e7f (self-updated from a June build), Windows 11 x64.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/10/2026, 6:05:13 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/10/2026, 2:41:03 PM
Editable. Press Enter to edit.

stack72 commented 7/10/2026, 3:36:24 PM

@catjen thanks for the detailed report! We've triaged this and the root cause is clear — rebundleAndUpdateCatalog() writes non-canonical Windows paths to the catalog, creating ghost rows that trip the I-Repo-1 assertion.

One thing we'd like to clarify before we implement the fix: how are you running swamp on Windows? Our release pipeline doesn't currently publish Windows binaries to the update channel, so swamp update wouldn't have a Windows artifact to pull. Are you compiling from source with deno compile, running via deno run, or getting the binary another way?

Knowing the exact setup will help us make sure the fix covers your actual workflow.

stack72 commented 7/10/2026, 6:05:21 PM

Thanks @catjen 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.