#1165 swamp extension update doesn't migrate existing model instances to the new typeVersion — new methods are 'Unknown' (persists after #869)

Confirmed: still reproduces after swamp update to the latest build 20260715.175955.0-sha.4d2897c1 (was 20260711.205210.0-sha.c8b5c983). On the new binary the full ladder was tried and none migrate the existing instance:

• swamp extension update @vcjdeboer/session-ingest → no-op ("already up to date v2026.07.15.2")
• swamp model evaluate ingest → rewrites the evaluated definition only
• swamp repo upgrade → updates repo settings/skills only

Instance remains typeVersion: 2026.07.12.1; swamp model method run ingest status still returns Unknown method 'status'. So the instance-migration gap is not addressed in 20260715.

Thanks for the detailed repro @vcjdeboer — this helped us track down what's happening.

There are two separate things going on here, and only one of them is a bug.

What we fixed in https://github.com/swamp-club/swamp/pull/1882

The "Unknown method" problem after extension update is caused by local source shadowing. When you have an extension both locally developed (source in a local models dir or .swamp-sources.yaml mount) and installed via the lockfile, resolveOriginConflicts silently clears the pulled entry's type in favor of the local source. So after swamp extension update pulls the new version, the local (old) source still wins — new methods aren't visible, and you get no feedback about why.

swamp extension update now warns when this happens, showing which types are shadowed and which local source is winning. The fix is to update your local source or remove it so the pulled version takes effect.

What's by design (for now)

The typeVersion on the model instance not advancing after extension update is intentional — extension update and model upgrade are separate concerns. extension update pulls new extension code. Model upgrade (advancing the instance's typeVersion and running upgradeAttributes on globalArguments) is opt-in and currently triggers as a side effect when you next run a method via swamp model method run, provided the extension model has an upgrades[] stanza.

There's no standalone swamp model upgrade command today. We may add one in the future, but it's not blocking method availability — new methods load from the model type registry regardless of the instance's stored typeVersion. The typeVersion field only controls the upgradeAttributes migration chain for globalArguments. There is work planned for this soon(ish)

The "corroborating signal"

The Last upgrade toVersion x does not match model version y errors from other users (@alvagante/content-blog-post, @magistr/obsidian/vault) are a different issue — that's a validation failure where the extension author's upgrades[] stanza doesn't match their model version field. Those models fail to register entirely. We can track that separately if it's still reproducing.

Confirmed resolved on this machine following your guidance — swamp 20260717.145236.0-sha.d0b3b256. Root cause was exactly local source shadowing. A few details that may be useful:

It was TWO shadows, per source-kind — and fixing one leaves a confusing half-working state. The suite is split (published + lockfile) but this repo also keeps pre-split local copies. There were two stale .12.1 shadows of @vcjdeboer/session-ingest:

• extensions/models/ (the default local models dir) shadowed the methods → the newly-published status method was Unknown method.
• extensions/reports/ (the local reports dir) separately shadowed the report → @vcjdeboer/capture-report kept rendering the wrong session.

Updating only extensions/models/ made status resolve correctly — but capture-report still ran the stale code from extensions/reports/. So a user can fix the models shadow, watch methods start working, and be baffled that a report (or other source-kind) is still stale. What fully worked: sync both local source dirs to the published version, then rm -rf .swamp/report-bundles/<hash> to force a recompile. Methods + report then both correct.

On the #1882 warning: I didn't see it fire here — swamp extension update @vcjdeboer/session-ingest printed "already up to date (v2026.07.15.2)" and no-op'd, because I'd pull --forceed the new version into the lockfile earlier, so update had nothing to pull. The shadow warning seems tied to an actual pull; when the lockfile is already current but a stale local source shadows it, extension update stays silent. A shadow check that also runs on the "already up to date" path (or in swamp doctor) would catch that variant.

Confirming your typeVersion point: the instance is still typeVersion 2026.07.12.1 and never advanced, yet every method incl. the new status is now available — so "methods load from the type registry regardless of the stored typeVersion" holds exactly here. 👍

Unrelated FYI (separate, not asking you to chase it): on this build swamp data query / swamp data list return 0 rows for models that demonstrably have data (swamp data get still works) — it surfaced as "0 local" in the new status output. Happy to open a clean repro if that's useful; otherwise ignore.

Thanks for the quick turnaround on #1882.