Limit/Continue vs Watch: Which Guarantees Consistent Pagination in k3os?

Retrieving Large Datasets Consistently

In k3os, a lightweight Kubernetes node OS, the Kubernetes API’s limit and continue parameters provide a stateless way to bound list responses. An alternative is to use a watch with a resourceVersion to receive near‑real‑time updates.

Concrete Constraint

The goal is to enumerate thousands of a single resource type (e.g., ConfigMaps) without missing or duplicating items, even as other clients create or delete objects concurrently.

Unresolved Behavior

When an update occurs precisely at the boundary of a paginated request—just after a page has been returned—the API server’s handling is undocumented. It is unclear whether such an update is reflected in the current page, the next page, or omitted entirely. Additionally, the opaque continue token may become invalid if the underlying data changes, potentially leading to duplicate or missing items across pages.

Specific Questions

• Does k3os guarantee that an item added or removed at the boundary of a paginated list will appear in the current or next page, or can it be lost?
• Can concurrent modifications invalidate a continue token in a way that causes overlap or gaps between successive pages?
• Is there a deterministic ordering or snapshot mechanism that ensures consistent pagination when the datastore performs compaction or reordering?