Problem
Concurrent aether mcp edits can silently drop saved server entries. LocalMcpStore does an unlocked read-modify-write and every writer uses the same mcp.json.tmp path. A process can report success after replacing another process's change.
On main at 67cb640, mutable, write, and add have no cross-process serialization or revision check. The same pattern affects update and remove.
Reproduction
I launched 12 Node processes against one temporary MCP registry and released them from a common barrier. Each process added a unique server with LocalMcpStore.add. All 12 exited successfully, but the final valid mcp.json contained only one server. This used the repository's compiled mcp_store.js; its TypeScript source matches current main for this module.
Expected behavior
If concurrent edits report success, all nonconflicting changes are present. If a write cannot be safely applied, that caller receives an explicit failure or retry result. No edit silently disappears.
Acceptance criteria
- Serialize the full read-modify-write transaction across processes, or use an equivalent conflict-detection/retry mechanism. A unique temporary filename alone does not prevent lost updates.
- Keep atomic replacement and existing corrupt/unreadable-registry refusals; do not expose stored auth tokens in errors or diagnostics.
- Add a deterministic multi-process barrier test for concurrent distinct adds. After all callers succeed, all names must be present; if a caller fails, it must be explicit and the registry must remain valid.
- Cover at least one conflicting update/remove case and interruption recovery so the locking mechanism cannot strand the registry or overwrite the last good file.
Scope
This is durability of the local MCP registry. It does not activate MCP tools in chat or change Cloud broker connections.
Problem
Concurrent
aether mcpedits can silently drop saved server entries.LocalMcpStoredoes an unlocked read-modify-write and every writer uses the samemcp.json.tmppath. A process can report success after replacing another process's change.On
mainat67cb640,mutable,write, andaddhave no cross-process serialization or revision check. The same pattern affectsupdateandremove.Reproduction
I launched 12 Node processes against one temporary MCP registry and released them from a common barrier. Each process added a unique server with
LocalMcpStore.add. All 12 exited successfully, but the final validmcp.jsoncontained only one server. This used the repository's compiledmcp_store.js; its TypeScript source matches currentmainfor this module.Expected behavior
If concurrent edits report success, all nonconflicting changes are present. If a write cannot be safely applied, that caller receives an explicit failure or retry result. No edit silently disappears.
Acceptance criteria
Scope
This is durability of the local MCP registry. It does not activate MCP tools in chat or change Cloud broker connections.