shared-mutable-index-rmw-race-use-marker-blob-per-item

Shared mutable index → use a marker blob/row per item (not a read-modify-written list)

Problem

You are building a feature where multiple producers concurrently register items into a shared collection, and a reader periodically prunes dead entries — e.g. a "see everyone's in-flight runs / active sessions / recent uploads" list shown on a home/dashboard page, shared across a team / workspace / user.

The tempting design is one shared mutable container that you read-modify-write:

# register (producer)                       # render + prune (reader)
ids = read(index)                           ids = read(index)
ids = [new_id] + dedupe(ids)                live = [i for i in ids if still_alive(i)]
write(index, ids[:CAP])                     write(index, live)   # prune

This has a read-modify-write race. Interleave two callers:

1. Reader reads [A].
2. Producer reads [A], computes [X, A], writes [X, A].
3. Reader writes its pruned copy [A] (computed in step 1, before X existed).

X is now permanently gone from the index. It is never re-added — registration fires once, at create time. So the very item the feature promises to surface silently never appears for anyone. It is not self-correcting (a common false assumption). The window is small, but it is exactly the "two people working at once" moment the feature exists to serve, and a janitor/prune reader widens it.

Context / Trigger Conditions

• You're DESIGNING (or reviewing) a shared "active items / recent items / running now / activity feed" index with concurrent writers and a pruning reader.
• The backing store is a single read-modify-written container: a JSON array in one GCS/S3/object-store blob, a DB array/JSON column, a shared cookie list, one file.
• Symptom in the wild: an item a colleague just created never shows up in the shared list; intermittent "missing entries" that no single user can reproduce; a code reviewer flags a race on the index write-back.
• Adjacent (the durable-pointer / reconstruction half of these features): see also in-memory-job-registry-orphans-cloud-result-on-restart and reconstruction-from-durable-store-must-replicate-completion-gate.