#666 Single __global__ datastore lock serializes unrelated writes across all repos/namespaces

Not resolved by swamp update + repo upgrade

Updated the CLI 20260609.232501.0-sha.873563f2 → 20260616.195738.0-sha.2c8bba58 and ran swamp repo upgrade. The __global__ lock contention is unchanged — datastore sync/compact/vault put still serialize behind a single global lock, so a write in one repo/namespace still waits on operations from any other sharing the bucket.

Note: swamp update/repo upgrade does not pull the @swamp/s3-datastore extension (still v2026.06.03.2 here), so the datastore behavior wouldn't change from a CLI bump alone — but flagging that the upgrade path did not surface or ship a datastore version that addresses this. Still reproduces on the latest CLI build.

Current mitigation on our side: de-aligned the polling intervals of the launchd jobs sharing the bucket (was 60/120/180s, all sharing a 60s beat → coincided every 180s; now 90/150/210s → coincide only ~every 630s) to reduce collision frequency. This narrows the window but does not address the single-lock serialization.

Root cause located — this is a swamp-core issue, not an @swamp/s3-datastore extension issue

Please re-route/re-scope: the __global__ lock is hardcoded in swamp core, not in the S3 datastore extension. Apologies for filing under the extension — the contention symptom surfaces through the S3 backend, but the lock-key decision lives in core.

Where

src/infrastructure/persistence/datastore_sync_coordinator.ts:

// line 81
export const GLOBAL_LOCK_KEY = "__global__";

// line 224 — the public entry point always passes the global constant
export async function registerDatastoreSync(options: RegisterDatastoreSyncOptions): Promise<void> {
  await registerDatastoreSyncNamed(GLOBAL_LOCK_KEY, options);
}

So every datastore sync — across every repo and every namespace sharing a bucket — serializes on the single key __global__.

Why namespacing does not help today

swamp datastore namespace set + migrate change the object prefix layout, but the lock-acquisition path never reads the namespace — it calls registerDatastoreSync, which hardcodes GLOBAL_LOCK_KEY. Verified locally: with zero namespaces registered, datastore compact/sync still acquire __global__. Migrating to namespaces would relocate objects but give no contention relief. So there is currently no swamp-native way to avoid the global lock other than reducing collision frequency (e.g. staggering scheduled writers).

Suggested fix (the plumbing already exists)

registerDatastoreSyncNamed(key, options) is fully key-parameterized — registerDatastoreSync is the only thing forcing the global constant. Deriving the key from the repo's namespace (or repo id) instead of hardcoding GLOBAL_LOCK_KEY would scope locks per-namespace, so a write to namespace A no longer blocks a write to namespace B. This looks like a small, well-contained change: thread the namespace through the single call site at line 224 rather than passing the constant.

Open question for maintainers: is the global lock intentionally coarse to protect the shared .datastore-index.json (one manifest for the whole bucket)? If the index is bucket-global, per-namespace locks would also need a per-namespace (sharded) index to be safe — otherwise concurrent namespaced writers would race on the shared manifest. If so, the index sharding from the earlier note in this thread and the lock-scoping fix are the same piece of work.