Relationships
↔ sibling #3117#2621 datastore config migrate checks the sentinel in the stale local cache and re-runs a full migration over a shared S3 datastore
Opened by stack72 · 9/28/2026· Shipped 10/6/2026
Problem
swamp datastore config migrate decides whether the datastore is already migrated by stat-ing the sentinel at datastoreResolver.resolvePath("config") (migrateConfigToDatastore in src/domain/datastore/managed_config_migration.ts). For a custom datastore such as @swamp/s3-datastore that path is the local cache. The command does not pull the config tier before checking, so a repo whose cache predates another repo's migration does not see the sentinel. It runs a full second migration and pushes its own local models, workflows, vaults, lockfile and pulled extensions into the shared config tier.
Reproduction (MinIO, released binary 20260928.174341.0)
- Three fresh repos A, B, C. Run
swamp datastore setup extension @swamp/s3-datastore --config ... --namespace e2ein all three first. swamp datastore config migratein A: migrates and pushes.swamp datastore config migrate --jsonin B: returns alreadyMigrated false, copies every source, and reports pushed true, instead of alreadyMigrated true.
If B is set up after A's migration (so setup hydrates the sentinel), B correctly reports already migrated. The outcome depends on when the local cache was last pulled.
Impact
The sentinel exists to stop duplicate work. Here a second instance overwrites the shared config tier with its local copy of any file at the same path. The manual already warns not to run migrate concurrently, but this happens sequentially.
Expected
Pull the config tier (or check the sentinel on the remote) before deciding. Found while verifying swamp-club#2458, which is a separate fix.
Shipped
Click a lifecycle step above to view its details.
Sign in to post a ripple.