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

Relationships

#1009 Orphaned data (migrated-away/deleted model) can't be GC'd or deleted

Opened by mgreten · 7/7/2026· Shipped 7/7/2026

Summary

Data whose owning model has been removed or migrated to another namespace has no cleanup path today: swamp data gc skips it (there's no model type to read retention/lifetime from) and swamp data delete <model_id> --all returns Model not found. The orphaned rows stay in the index indefinitely, inflating index size (and, on a monolithic local index, the per-write sync cost).

Steps to reproduce

  1. Have data written by a model, then remove that model's definition from the repo (or migrate the model instance to a different namespace, leaving its historical data behind in the old namespace — this is how I hit it, after splitting a pr-feed model out to a separate watchers namespace).
  2. The data rows remain in the original namespace's catalog (here: ~53k rows across two pr-feed model_ids, all frozen at the migration date, nothing writing them since).
  3. Try to clean them up:
swamp data gc --force --json
  → reclaims almost nothing (~12 of ~50k orphaned rows); GC only enforces the
    lifetime/version-cap declared on a live model type, and there's no type here.

swamp data delete 4690bfcb-39ba-4f32-8db2-b941587ce166 --all --json
  → { "error": "Model not found: 4690bfcb-39ba-4f32-8db2-b941587ce166" }

So the rows can be neither GC'd nor deleted through the normal commands.

Impact

On this namespace the orphaned pr-feed data is ~43% of the catalog. Combined with a monolithic local index (see the migrate-index bug and swamp Lab #829), it directly inflates the whole-index sync paid on every write. There's currently no supported way to remove it short of low-level datastore surgery.

Suggested fix

A way to prune orphaned data — e.g. swamp data delete --model-id <id> --all that works even when the model definition is gone, or a swamp datastore prune-orphans that drops catalog entries whose model no longer exists in the namespace (with a --dry-run). GC could also optionally treat orphaned-model data as expired.

Environment

  • @swamp/s3-datastore 2026.07.02.1
  • swamp 20260706.015952.0-sha.a3f4a37c
  • MinIO backend, single namespace

Thanks — happy to provide the exact catalog rows or test a fix against this data.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 8 MOREREVIEW+ 3 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/7/2026, 4:07:37 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
keeb assigned keeb7/7/2026, 2:50:55 AM
Editable. Press Enter to edit.

keeb commented 7/7/2026, 4:07:42 AM

Thanks @mgreten for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

mgreten commented 7/7/2026, 1:25:06 PM

Thanks so much for the fast turnaround on this! Wanted to close the loop with a verification result.

I updated to the latest published CLI (swamp 20260707.035329.0-sha.84dbdd93) and re-ran the repro, but the orphaned-model delete still errors the same way:

swamp data delete 4690bfcb-39ba-4f32-8db2-b941587ce166 --all --dry-run --json
  → { "error": "Model not found: 4690bfcb-39ba-4f32-8db2-b941587ce166" }

swamp update reports I'm already current, and data delete / data gc show no new flags, so I think the merged fix just hasn't made it into a released build yet (the "release is on its way" from the ship note). No worries at all — just flagging in case the release step is still pending on your side, since the issue's marked shipped.

Happy to re-verify the moment a build lands with it — I've still got the ~53k orphaned rows here as a ready test case. Thanks again!

Sign in to post a ripple.