feat(core): validate a query's reads by table generations, rerunning up to three times

[nickruigrok]

Fifth and last stacked PR for GRA-243. Stacked on #391 and #393; this PR's own change is the last commit.

What

Spec 6.3: a multi-read query validates its dependency generations when it completes, reruns up to three times, then returns the retryable query.concurrent_change. It is never answered from an inconsistent read set.

• Table generations (sdk_tables.generation, migration 0005). Every commit that changes a table's records moves its generation on once. A commit that changes nothing, or changes other tables, doesn't.
• Reads answer their dependencies. StoreHost.read returns { value, generations }, the table's generation read in the same transaction as the answer. StoreHost.generations reports the current generations by name.
• StoreReader (apps/core/src/store-reader.ts) is the host-side per-invocation reader from decision D1-A. It records the generation each read saw (two reads of one table at different generations make the set stale), and it records get revision assertions on found records as guards for GRA-244's commit.
• readConsistently(store, scope, operation) runs the operation with a fresh reader and answers only once isCurrent() holds. It allows 1 run plus 3 reruns (queryMaxReruns), then throws query.concurrent_change with details: { retryable: true }.
• Invalidation: a read that matched nothing still depends on its table, so an insert invalidates an empty query.
• RPC: a read's result crosses RPC as JSON text. RPC types can't carry its documents nested beside the generations; openStore validates the shape.

Boundary

GRA-244 wraps query handlers in readConsistently, builds ctx.db with databaseReader(schema, (request) => reader.read(request)) and hands reader.guards() to its commit. Live-query delivery of invalidations is a later slice.

Tests

apps/core/test/store-reader.test.ts, in workerd through OpenStore and the DO. Commits land between reads through the store, exactly as another caller's would.

• One run when nothing changes.
• A commit between two reads gives a second run, answered from a consistent state, never the first run's.
• Persistent contention gives query.concurrent_change, retryable, after 4 runs.
• An empty query goes stale after an insert.
• Other-table and no-op commits keep reads current; a real change doesn't.
• Guards are recorded only for found records that asserted a revision.

Results: vp check is clean. vp test on store-reader, store-cursors, store-queries, store-indexes, store-expressions, the data-store suites, SDK database and shared store-queries passes 177 tests.

[nickruigrok]

@greptileai review

[greptile-apps]

Confidence Score: 5/5

[Critical impact] The PR appears safe to merge, with a non-blocking issue that can cause needless retries for refused reads.

Findings

1.  Refused reads retry unnecessarily ▶

Fix with agent prompt

### Issue 1
apps/core/src/store-host.ts:589-594
`#withGenerations` adds a table dependency even when `readableTable` throws `data.access_denied` before reading any records. If other callers keep changing that table, the query can run four times and return `query.concurrent_change` instead of the permission error or the handler's fallback answer.

Only attach generations when the failed read actually depended on records.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds table generations and StoreReader so multi-read queries can retry when their reads span different states.

• Queries rerun when their reads span different table generations.

Diagram

sequenceDiagram
  participant Handler
  participant Reader as StoreReader
  participant Store as StoreHost
  Handler->>Reader: read(request)
  Reader->>Store: read(scope, request)
  alt Read succeeds
    Store-->>Reader: value and generations
    Reader-->>Handler: value
  else Read fails
    Store-->>Reader: error with generations
    Reader->>Reader: Record and remove generations
    Reader-->>Handler: error
  end
  Reader->>Store: generations(tables)
  Store-->>Reader: Current generations
  alt Reads are current
    Reader-->>Handler: Keep answer or error
  else Reads are stale
    Reader->>Handler: Run again, up to three times
  end

Loading

_{Reviews (2) · Last reviewed commit: "fix(core): count a failed read's generat..." · Reviewed by Greptile}

[nickruigrok]

@greptileai review

[greptile-apps]

Refused reads retry unnecessarily

#withGenerations adds a table dependency even when readableTable throws data.access_denied before reading any records. If other callers keep changing that table, the query can run four times and return query.concurrent_change instead of the permission error or the handler's fallback answer.

Only attach generations when the failed read actually depended on records.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/core/src/store-host.ts
Line: 589-594

Comment:
**Refused reads retry unnecessarily**

`#withGenerations` adds a table dependency even when `readableTable` throws `data.access_denied` before reading any records. If other callers keep changing that table, the query can run four times and return `query.concurrent_change` instead of the permission error or the handler's fallback answer.

Only attach generations when the failed read actually depended on records.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.