Design a Reactive Database (Live Queries), stage 3 of 9: break it
The task that never appeared
The first version of the read-set recorder is below. Select the lines that explain the bug.
System so far· 5 parts
Select a component to see what it is responsible for and which state it owns.
- 1Web and mobile apps → Sync servers: Subscribe and mutate
- 2Sync servers → Function runners: Run a function
- 3Function runners → Versioned store: Read at a snapshot
- 4Versioned store → Subscription tracker: Committed writes, in order
- 5Subscription tracker → Sync servers: These subscriptions changed
- 6Sync servers → Web and mobile apps: New results
- Request / response
- Asynchronous
- Server push
What you need to know
0 of 1 checks done
A query depends on what it didn't find as much as on what it found. "Tasks in Backlog" depends on there being no other Backlog tasks; a new one changes the answer.
Rows that appear inside a range a query already scanned are called phantoms.
Check
The recorder saves the keys of rows a scan returned. A new task is inserted into the scanned column. Does the query re-run?The fix is to record the range scanned (from, to), including its empty parts, and check each written key with an interval test: does it fall inside any recorded range?
A move changes two keys: the old one leaves a range, the new one enters another. Both must be checked.