Optimistic ordered-window departure review (#2169, related #2148)#

Contract and repair location#

The reported #2169 window kept [3, 2] while an optimistic membership-removing update persisted. The issue's maintainer comment accepts an immediate short window as the way to preserve optimistic visibility while a provider refill is pending. #2148 shows a related joined/anti-joined path: the departure is visible, but acquisition does not make useful refill progress. These are two obligations, not one expected final row array.

The accepted law is in packages/db/src/query/live/ARCHITECTURE.md#atomic-window-publication. An optimistic overlay is not an authoritative loss of provider coverage. Collections and Effects publish its membership departure synchronously. They recompute over installed rows, even if that produces a short window. If the provider has a useful missing row, bounded acquisition starts while the mutation persists. A provider write queued behind that mutation remains private until its sync transaction applies; publication can precede resolution of the applied-receipt promise. Rollback removes this overlay and recomputes from the current base and any remaining overlays. The prior window is restored only in an otherwise isolated history.

The repair is in the ordered source loader. A visible delete or order change normally invalidates the authoritative source prefix and starts a gated repair. That classification was also applied to optimistic overlay departures. The loader now consults the source Collection's active overlay for the changed key: it still sends the change into the graph and asks for needed finite refill, but does not claim authoritative source-order loss. Existing initial-load, window-move, and authoritative-repair barriers remain in force.

Executable evidence#

The primary owner is packages/db/tests/query/ordered-work-oracle.property.test.ts. Its controlled provider has a separate six-row ledger. An independent reference recomputes the public window from explicitly installed IDs and one overlay, then sorts and slices it. Rows below the visible boundary distinguish bounded refill from full-source overfetch. The 96-cell core grammar crosses source, joined, and anti-joined filters; update and delete; Collection and Effect; acknowledgement and rollback; one- and two-row windows; and indexed and unindexed loading. Two indexed controls install the replacement independently of the query shape. A non-prefix control installs rows 3 and 1 while row 2 is absent: deleting 3 must show [1] immediately, then acquire 2 and show [2].

Eight histories settle acknowledgement or rollback before the held provider answer, for source and joined paths and both consumers. Eight more mutate the joined-side marker rather than the root, for joined and anti-joined paths, both outcomes, and both consumers. The provider answer arrives after marker settlement in those histories. The driver records the immediate public rows and callbacks before yielding, provider acquisition while persistence is held, the queued-answer and transaction-settlement cuts, the late-answer cut, and two subsequent task turns. It checks both public rows and publication sequences. A separate installed-extent model checks ascending heads, descending offset windows, a tied head, and an exhausted window across both outcomes. The tied case removes whichever equal-ranked key the initial public window chose, avoiding an unsupported tie-break promise.

Four controlled histories use ascending limit-one on-demand joined and anti-joined plans, the published #2148 shape. A rank-only acknowledgement is an adjacent control, while a combined rank-and-membership departure checks rollback. An acknowledged joined-side marker departure is followed by marker restoration: source row 3 must return with a Collection or Effect publication. This keeps marker eligibility distinct from source installation in the model.

The provider recorder keeps submitted IDs, requested order direction and limit, real applied-receipt state, and every request's predicate, rank scope, identity, phase, and progress. A required refill must submit the useful row through a finite ordered request no larger than width + 2 in this fixture. Every pending indexed acquisition must have that bound or be a one-rank tie probe. A source-filter request must reject an ineligible peer at a relevant rank. A repeated identical request in the same settlement phase without a new row fails. Distinct sequential tie or refill requests are allowed. The six-row ledger makes full-source work distinguishable from a finite bound. An emergency eight-request ceiling catches runaway work but is not a fixed-point proof. Hostile checker controls reject no refill progress, delayed Collection publication, stale post-settlement publication, full-source overfetch, a missing source predicate, broad work after a valid refill, and acquisition deferred until settlement. Named finite waits let a stalled held event enter cleanup with its checkpoint intact.

The original loader behavior was reintroduced locally without changing the oracle. The width-two indexed source-delete/Collection acknowledgement case then failed at the intended cut: immediate [3, 2] instead of [2], no immediate callback, and a delayed settlement publication. Restoring the loader change passes the focused histories. The exact #2169 mutation-handler utils.refetch() path also runs through a real Query DB adapter and QueryClient: only rows 3 and 2 are initially installed, so the immediate window is [2], not [2,1]; after the handler changes the provider row and refetches, row 1 applies and the window becomes [2,1]. Temporarily restoring the old loader classification fails this receiver at the immediate checkpoint with [3,2]. The receiver also checks that the held callback snapshots remain [2] and that the settled [2,1] window reaches subscribers. A temporary observer mutant that discarded the final callback failed at that assertion. Its request checker evaluates an unordered probe's uncapped predicate against the full ledger and an added equal-rank peer; an orderless limit: 1 cannot masquerade as a rank-tie probe. With TANSTACK_DB_ORACLE_SEED=1, the complete ordered-work owner passes 267 tests with no type errors; the Query DB receiving test also passes with runtime and type checks. An unrelated generated history at seed -1704903709 fails both with and without this loader change; it is not claimed as a regression or silently counted as green.

Three fresh independent oracle-review attacks identified the missing joined-side, late-answer, explicit-installed-set, and bounded-request distinctions; those are now executable. They also caught stale claims about receipt timing and request-count stability, which this review and coverage map correct.

Boundaries and receiving work#

#2148 does not publish its exact historical provider ledger or release schedule. The controlled ascending limit-one joined/anti-joined histories reach its stated shape, but the ordered-work owner still owns any recoverable historical replay. invalidateLoadedSubsets() is introduced by open PR #2154, not this revision; its Query DB owner needs a during-hold immediate-window witness when that API is integrated. The installed ascending, offset, tie, and exhausted cases establish immediate local publication, not all provider-refill schedules for those windows. Provider rejection, overlapping optimistic transactions, rank-only rollback and other rank-move histories, real framework render timing, and exact callback payloads remain separate obligations. A provider-rejection continuation needs a Collection-versus-Effect contract decision before adding expectations. The two post-settlement task turns are bounded observations, not a universal no-retry proof.

Oracle-guide accounting#

This audit covers the change from published base c4071fdba through the working-tree evidence above. Recheck the final commit after preparation; a passing seeded run is not a claim about every generated history.