docs: document bounded occurrence pages
This commit is contained in:
@@ -111,7 +111,8 @@ executing mark, and the next startup recovery abandons it truthfully.
|
||||
A currently held (unadmitted) candidate is synthesized as a `pending`
|
||||
row at the top of the first page; once admitted, the durable
|
||||
`admitted` entry replaces it. While a candidate is held, the first
|
||||
page may carry one row more than `limit`.
|
||||
page still honors `limit`; with `limit=1`, its continuation cursor is an
|
||||
opaque marker that resumes the stored history from its first row.
|
||||
|
||||
## Administration surface
|
||||
|
||||
|
||||
@@ -361,9 +361,10 @@ recording as dispatch; restart recovery still repairs torn boundaries.
|
||||
Known limitations: pointing one composition's stores inside another live
|
||||
composition's store subtree (without sharing its identical roots) is
|
||||
unsupported operator error; `max_steps: None` means "unpatched" on
|
||||
update (a set budget cannot be cleared back to unset); a first
|
||||
occurrence page may carry one row more than `limit` while a candidate is
|
||||
held; calendar iteration within a tick may use the tick-start source
|
||||
update (a set budget cannot be cleared back to unset); a pending occurrence
|
||||
projection still honors the requested page limit, using an opaque continuation
|
||||
cursor when `limit=1` so the first stored row remains reachable; calendar
|
||||
iteration within a tick may use the tick-start source
|
||||
(trigger edits take effect on the next tick).
|
||||
|
||||
## Verification gates
|
||||
|
||||
Reference in New Issue
Block a user