Skip to content

rename-namespace races concurrent upserts: source namespace resurrected, state split across namespaces #16

Description

@Coriou

Found by adversarial audit @ 261d00b, survived refutation (conf 0.93).

Interleave: rename-namespace runs scanKeys snapshot → dropIndex(source) (clears knownIndexes/dimensionMap, translate/index.ts:180-181) → per-key RENAME loop → registry srem/sadd → ensureIndex(target) — no transaction or per-namespace lock (pendingIndexCreations only coalesces same-index FT.CREATEs; namespaces.ts:88-114). A concurrent POST /upsert/source mid-loop passes loadDimension (map cleared), recreates idx:source via FT.CREATE, writes v:source:* hashes, SADDs source (upsert.ts:139) — rename's later SREM (namespaces.ts:103) removes that registration: final state has a live idx:source index plus orphan v:source:* keys invisible to list-namespaces (reads only _ns_registry) but fully queryable. Crash windows mid-loop persist the same split; syncIndexes repairs only index→registry direction, never this.

Fix direction: serialize mutating namespace operations per-namespace (in-flight map pattern like pendingIndexCreations) or perform the move atomically (Lua).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingpriority: mediumWorth doing; not urgent

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions