A query with a causal bookmark validates the bookmark before entering the normal active query and timeout lifecycle.
If the backend has not reached the bookmark’s storage sequence, the request can wait using the backend’s longer bookmark-wait limit rather than the caller specified max_runtime_ms. During that wait, the query is not yet in the active query map so it cannot be cancelled.
Expected behavior:
- Bookmark waiting consumes the same runtime budget as the query.
- A query times out if the bookmark is not satisfied before its deadline.
- A cancel request interrupts an in progress bookmark wait.
- The read does not execute after timeout or cancellation.
Proposed fix:
- Keep the current bookmark graph/cell ownership check in the request preparation code
- Move the storage sequence wait into the query execution block after the request has been registered as active (to allow cancellations)
- Make the wait obey the specified time budget and cancellation token
- Apply this to both direct row execution and prepared/paged execution
A query with a causal bookmark validates the bookmark before entering the normal active query and timeout lifecycle.
If the backend has not reached the bookmark’s storage sequence, the request can wait using the backend’s longer bookmark-wait limit rather than the caller specified
max_runtime_ms. During that wait, the query is not yet in the active query map so it cannot be cancelled.Expected behavior:
Proposed fix: