Skip to main content
← Back to list
01Issue
FeatureClosedSwamp CLI
AssigneesNone

#200 Document and surface a native cache-refresh path so agents stop doing cache surgery

Opened by bixu · 5/1/2026

Problem

When an extension behaves unexpectedly after swamp extension pull --force, it is not obvious how to force swamp to actually pick up the new bundle. In a recent debugging session I (an LLM agent) ended up doing destructive cache surgery — rm -rf .swamp/bundles && rm -f .swamp/_extension_catalog.db* — to get swamp to load a freshly-pulled bundle, because pulling alone (even with --force) did not invalidate the catalog and the model kept executing the old code path. That is the wrong instinct for an agent: it bypasses swamp's invariants and risks breaking other state.

The correct command turned out to be swamp extension update <name>. Once I used it, the new bundle loaded immediately and cleanly. But there was nothing in the --help output, error messages, or logs that pointed me there. The visible options after pull not seeming to take effect were:

  • swamp extension pull --force (insufficient — catalog still resolved old bundle)
  • delete files under .swamp/ manually (worked but is invasive and undocumented)

Why this matters for agents

Coding agents make decisions from --help output and error messages. When the natural-looking command (pull) doesn't fully refresh the runtime, and the actual fix (update) isn't surfaced anywhere near the symptom, agents will reach for rm -rf long before they discover the right subcommand. That's both unsafe and embarrassing.

Proposed fixes (any subset would help)

  1. Make swamp extension pull --force invalidate the resolution catalog so the next swamp model method run picks up the new bundle without an additional command. If pull cannot do this for some reason, document the constraint inline.
  2. In swamp extension pull output, mention swamp extension update as the recommended path for refreshing an already-installed extension to a newer version.
  3. Add a one-line hint when a model resolves to a stale bundle — e.g., when the in-flight bundle hash doesn't match the latest pulled extension's hash, log "hint: run swamp extension update <name> to refresh".
  4. Document this in the swamp-troubleshooting skill (and any agent-facing docs): "if a freshly-pulled extension doesn't seem to take effect, use swamp extension update, not file deletion."

Concrete repro

  1. swamp extension pull '@hivemq/harvester/kubeconfig' --force — claimed to extract new files
  2. swamp model method run <model> fetch — still ran the old code path
  3. After file-system surgery (rm -rf .swamp/bundles .swamp/_extension_catalog.db* + re-pull), new code loaded
  4. Later discovered swamp extension update does the same cleanly
02Bog Flow
OPENTRIAGEDIN PROGRESSCLOSED

Closed

5/6/2026, 11:06:54 PM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

stack72 commented 5/6/2026, 11:06:41 PM

Closing — verified fixed on current main.

Empirical reproduction across three variants (pull --force, update, pull without --force) all produce identical clean catalog transitions: 106 rows move from 2026.04.23.32026.05.02.1, zero stale rows remain, method execution uses new code.

Root fix: W2 (#231 / PR #1295) introduced InstallExtensionService. Phase 8 (install_extension_service.ts:168-182) detects existing aggregates at a different version and atomically tombstones them via saveAll([tombstoneAll(vOld), vNew]) in a single SQLite transaction. Both pull --force and update converge on this path.

The dangerous behavior (stale catalog requiring rm -rf surgery) is structurally impossible after W2. Reported swamp version was 20260206.200442.0 — predates W2.

The original UX proposals (mention update in pull output, stale-bundle hint, troubleshooting docs) were workarounds for the underlying bug and aren't needed now that the bug is gone.

bixu commented 5/8/2026, 12:12:09 PM

Nice!

Sign in to post a ripple.