Skip to main content
← Back to list
01Issue
BugShippedExtensions
Assigneesstack72

Relationships

#1033 S3 datastore push walks the entire cache root — nested/foreign namespace dirs become doubled index keys (recurring)

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

First off — thank you for shard-first v2 and the per-namespace locking work; both made today's diagnosis and repair far more tractable than it would have been a month ago.

We hit a recurring index corruption (twice: 2026-06-27 and 2026-07-08) and root-caused it today from the bundle source. Sharing the full evidence chain in case it's useful.

What we observed

The datastore index accumulated hundreds of thousands of double-prefixed entries (agentic-tooling/agentic-tooling/…) that looked like phantoms. On the 2nd occurrence: 371,989 of 631,410 entries (index grown to 287MB), which pushed shards over the upload ceiling and wedged every write. A sibling repo's namespace (watchers) turned out to be the live carrier with another 270,106 doubled keys (index 175MB → 45MB after strip).

Root cause (traced in the s3.js bundle, v2026.07.02.1)

The keys weren't phantoms — they were real objects with real index entries. The local cache root (~/.swamp/repos/<id>/) had accumulated a nested directory named after the namespace itself (with its own .namespace.json, data/_catalog.db, etc. — a full second store copy, 1.9GB/389,959 files) plus sibling copies of five foreign namespaces. Because push's walk covers the whole cache root and (with an empty S3 prefix) uploads paths verbatim, the nested tree gets uploaded and indexed as doubled keys. Index-add timestamps cluster in batches of exactly 25 (DEFAULT_PUSH_CONCURRENCY), consistent with normal pushChanged walks. We found the same pollution on all four cache roots across two machines.

Two adjacent findings from the repair, offered as data points:

  • One sidecar had dirtyPathsOverflowed: true with doubled paths queued — as far as we could tell, a post-cleanup push would then have issued mass deletes for the doubled keys. We purged the cache dirs and reset the sidecars before any push, so this is unconfirmed-but-plausible rather than observed.
  • After index repair we also found the reverse skew: 215 objects present in S3 but absent from the index (recoverable via a listing walk, but there's no self-heal in that direction today).

We haven't identified what created the nested copies (the oldest carries a registration date of 2026-06-18) — possibly a mis-scoped invocation on our side. We've added a local watchdog tripwire that alerts on the signature, so we'll capture the creator if it recurs and will happily follow up here.

Ask (gently)

Would it be feasible for push to constrain its walk to the store's own expected layout, or to validate/refuse keys that resolve outside the configured namespace before indexing/uploading them? Either would turn this failure mode from silent index growth into a visible error. We have full artifacts (pre-purge cache listings, stripped-key manifests, timestamp histograms) and are glad to share any of it, or to test a candidate fix against our setup.

Environment

CLI 20260708.012813 / @swamp/s3-datastore 2026.07.02.1 / MinIO (forcePathStyle), two writer machines (macOS + Linux), namespace at bucket root plus prefixed sibling namespaces.

Upstream repository: https://github.com/systeminit/swamp-extensions

Environment

  • Extension: @swamp/s3-datastore@2026.07.02.1
  • swamp: 20260708.012813.0-sha.0f7166fe
  • OS: darwin (aarch64)
  • Deno: 2.8.3
  • Shell: /bin/zsh
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/8/2026, 8:12:22 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/8/2026, 6:33:40 PM
Editable. Press Enter to edit.

stack72 commented 7/8/2026, 8:12:36 PM

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