# Reconcile a merged frontier from retried paginated partitions Compute a safe combined progress frontier from independent partition checkpoints, including explicit normalization of inclusive and exclusive finality endpoints. Exact reference: {"kind":"skill_version","skill_id":"skl_B9m2E3Rc_DpW3H-7HvnFPw","version_id":"skv_qZcOkdjR2nHusqREEi37Mw"} Applicability: [{"constraint":"independent-partitions-with-shared-finality-coordinate","technology":"paginated-event-streams","version_scheme":"unknown"}] # Reconcile a merged frontier from retried paginated partitions ## Use when Several partitions of one event source are fetched with independent pagination tokens, and a consumer needs one statement of how far the combined stream is complete. A retry may finish after a newer attempt. This procedure assumes each partition has a documented complete traversal and finality rule, stable event identities, and a durable way to make replayed effects harmless. ## Keep partition progress separate For each partition and query scope, persist its opaque resume token, a source-certified complete-through watermark in a shared ordering coordinate when available, and a checkpoint generation. Keep event receipts or equivalent sink idempotency for replay. A token is a fetch handle; it is not a watermark and tokens from different partitions have no ordering. Process a page under the partition's own durable page barrier. Promote its next token and complete-through watermark only after all work covered by that barrier has a durable terminal outcome and the provider's coverage and finality contract supports the watermark. Use a compare-and-swap on that partition's token, generation, and scope. When a retry loses, reread the winner; do not combine its stale token or watermark with a newer checkpoint. ## Derive the combined frontier 1. Fix the set of partitions and its membership epoch. Include every partition that could contain an event at or before the proposed frontier. 2. Read one durable checkpoint per partition from that epoch. For each, establish the latest coordinate through which the provider guarantees complete enumeration and finality and the consumer has completed the corresponding work. The largest event merely observed or applied in a sparse partition is not such a coordinate. 3. If all coordinates share the same order and their endpoint inclusion semantics have been normalized, publish the minimum of those complete-through watermarks as the combined safe frontier. A fast partition cannot carry the combined frontier past a slower one. 4. If the source supplies no comparable complete-through coordinate, expose the checkpoint vector and do not manufacture a scalar frontier from token strings, page counts, or event maxima. 5. Recompute after a partition checkpoint changes. A late retry may leave a partition unchanged or advance it through a valid compare-and-swap; it must never reduce its durable watermark. Publish the combined frontier with its membership epoch so readers can detect a topology change. A quiet or empty page advances a partition's complete-through watermark only if the provider explicitly gives that response finality semantics. Otherwise the partition continues to hold the combined frontier. ## Normalize boundary inclusion before merging A complete-through proof must say whether its upper endpoint is included. Treat each partition checkpoint as a certified interval, not merely a numeric coordinate. Normalize the proofs to one interval convention before taking their minimum, preserving an open or closed upper boundary. If the weakest proof excludes its endpoint, the merged claim excludes that endpoint too. Do not turn an exclusive bound into an inclusive predecessor unless the source defines a discrete coordinate order and that predecessor is known. If endpoint semantics cannot be established, retain the checkpoint vector instead of publishing a scalar completeness claim. For example, partition A certifies all coordinates strictly before 100, while partition B certifies coordinates through and including 100. The combined coverage is strictly before 100, even though both certificates name 100. Reporting complete through and including 100 would claim A's unproven equality group. A dense timestamp order has no greatest coordinate below 100, so inventing an inclusive predecessor is not a valid repair. This is a reasoned boundary example; no implementation or tests were executed. ## Membership changes Before adding a partition to an existing frontier, prove that it has complete coverage from the previous published frontier or replay and process its earlier range. Before removing one, prove it is sealed through the cutover coordinate. Use a new membership epoch for the cutover. If either proof is unavailable, withhold a new scalar frontier and retain the vector; silently excluding a lagging or newly discovered partition can turn an old completeness claim into a gap. ## Reasoned example Partition A is complete through coordinate 120, while partition B is complete through 90. A retry of an older A page finishes late, but loses its partition checkpoint comparison. The combined safe frontier remains 90. When B later proves complete through 110, the frontier becomes 110. Taking the maximum, 120, would claim completion of B's unproven interval. These numbers illustrate the rule; no implementation or tests were executed. ## Validation boundary In a real implementation, verify the provider's ordering, pagination, retention, and finality contracts. Exercise page replay, a lost checkpoint response, a stale concurrent retry, an empty page, a stalled partition, a partition membership change, and mixed inclusive and exclusive endpoint proofs with tied coordinates. The minimum rule is justified only by complete-through evidence for every included partition; it does not establish exactly-once effects at an external sink. ## Supporting basis and limitations Reasoned from the existing requirement that every included partition support the merged completeness claim. The linked maintenance conversation identifies the mixed-endpoint counterexample. No provider contract, implementation, or tests were examined or executed. ## Change and rationale Clarifies that per-partition finality endpoints must be normalized before merging and adds a concrete mixed-endpoint example and validation case. The minimum of numeric coordinates can overclaim completeness when one partition certifies only coordinates strictly before an endpoint while another includes that endpoint. An explicit interval boundary makes the existing frontier rule safe without changing its partition or retry guidance.