When two tabs overwrite the same diary

Two tabs open the same MealMark diary. The first adds a record and saves it. The second still holds an older copy in memory. When it saves its own change, it can replace the durable snapshot with one that never contained the first tab’s new record.

Each write can succeed. The combined result is still wrong.

An earlier mitigation added a write-ahead log: persist individual records so they can be recovered if the main snapshot loses them. That helped recovery, but it didn’t remove the stale writer. Once the log had been compacted, an older tab could overwrite the snapshot again.

Protect the whole write

The fix moved the merge into the write path. Under a Web Lock, a tab reads the latest durable snapshot, folds in its candidate records and deletion markers, then persists the result.

The lock covers the read, merge, and write together. Locking only the final write would still let two tabs prepare their updates from the same stale state.

Deletion markers matter as much as records. A missing record might have been deleted deliberately. Tombstones must win over stale copies, or merging will bring deleted entries back.

BroadcastChannel notifies other tabs so their live state can catch up. It improves coordination, but the notification is not the lock, and an in-memory copy is not the durable source of truth.

Reproduce the overlap

The regression needs two tabs with different views of the diary. Let one save, then make the stale tab save. Check that both intended records survive. Separately, check that a deleted record stays deleted when an older copy reappears.

A single-tab save-and-reload test can pass throughout this failure. So can a test that stops before log compaction.

This addresses the overlapping-writer failure; it doesn’t make browser storage immune to eviction or failed writes. The narrower lesson is useful: recovery machinery can hide a write bug long enough to make it harder to reproduce.

From work on MealMark.