Skip to content

fix: re-validate compaction boundary to prevent missed deletion events in watch - #7

Open
Kasuki354 wants to merge 1 commit into
morriganreza973:mainfrom
Kasuki354:fix/watch-race-condition
Open

fix: re-validate compaction boundary to prevent missed deletion events in watch#7
Kasuki354 wants to merge 1 commit into
morriganreza973:mainfrom
Kasuki354:fix/watch-race-condition

Conversation

@Kasuki354

Copy link
Copy Markdown

Summary

Fixes issue #5: Race condition where Watch misses deletion event near compaction boundary.

Root Cause

In watch(), the compaction boundary check (startRev <= compactMainRev) and the watcher registration happen under both s.Mu and s.store.Mu locks. However, there is an edge case: if the watcher is added to the unsynced group with a minRev that is valid at check time, but compaction advances before syncWatchers() runs, the watcher could read compacted data and miss the deletion event.

Fix

  1. watch(): After adding watcher to unsynced, re-validate minRev against compactMainRev. If compaction advanced, cancel the watcher immediately with ErrCompacted.

  2. syncWatchers(): Re-check compactMainRev for every unsynced watcher before any data read attempt. If minRev <= compactMainRev, cancel with ErrCompacted.

  3. Both checks happen under s.Mu + s.store.Mu locks, ensuring atomicity with compaction.

/claim #5

… prevent missed deletion events

The race condition occurred when a watch was created with startRev close to
the compaction boundary. If compaction advanced between the boundary check
and the watcher registration, the watcher could be added to the unsynced
group with a minRev that had already been compacted, causing it to silently
miss deletion events.

Fix:
1. In watch(): after adding watcher to unsynced, re-validate minRev against
   compactMainRev. If compaction advanced, cancel the watcher immediately
   with ErrCompacted.
2. In syncWatchers(): re-check compactMainRev for every unsynced watcher
   before any data read, ensuring no watcher reads compacted data.
3. Both checks happen under s.Mu + s.store.Mu locks, ensuring atomicity.

Resolves morriganreza973#5
@opirebot

opirebot Bot commented Aug 7, 2026

Copy link
Copy Markdown

😅 Unfortunately there are no rewards left to claim in this issue!

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant