Preserve endpoint semantics when publishing a merged event frontier

Use when

Several independently paginated partitions contribute to one event stream, and their durable checkpoints certify coverage in a shared total order. Some source claims mean all events before a coordinate are final; others mean all events through that coordinate are final. Fetch retries or lost publication responses can finish after a newer checkpoint. This procedure assumes stable query scope and partition membership for each published frontier, durable terminal outcomes for the covered events, and a provider contract that makes each coverage claim final.

Represent the boundary explicitly

Store each partition's certified coverage as a coordinate plus an endpoint kind:

• Before x: every event with position strictly less than x has been completely enumerated, finalized by the source, and given a durable terminal outcome.
• Through x: the same guarantee also includes events at x.

Keep the provider's opaque continuation token, checkpoint generation, query scope, and membership epoch separately. A token or the greatest event observed is not a coverage boundary. Do not manufacture an exclusive boundary by adding a small increment to a timestamp or other coordinate unless the source defines an exact successor operation.

For the same coordinate, before x is the weaker, earlier cut; through x is the stronger, later cut. Across different coordinates, use the source's documented total order. If coordinates cannot be compared across partitions, retain a checkpoint vector and withhold a scalar frontier.

Publish and reconcile

1. Fix the partition membership epoch and read a durable checkpoint for every partition that could contribute an event before the proposed cut. Reject missing checkpoints, mismatched query scopes, or unsupported finality claims.
2. Normalize every certified boundary to the coordinate and endpoint-kind representation. Take the earliest cut across the complete vector. Publish that exact cut and the membership epoch. Never relabel before x as through x merely because both contain the same coordinate value.
3. Fence publication with a stored publication revision and membership epoch. Within one epoch, accept only a boundary at least as advanced as the current published boundary. A late retry that loses the conditional write must reread the current publication and partition checkpoints before proposing another cut.
4. If the publication response is lost, read the authoritative publication record. A record in the same epoch at the proposed cut or farther confirms that the public progress claim is present, regardless of which worker wrote it. If it is behind, recompute from current durable checkpoints and retry the conditional publication. If the epoch changed, apply the membership cutover rule before making another scalar claim. Do not infer publication success or failure from the missing response alone.
5. If the application must prove which attempt wrote the record, store a publication operation identifier. Boundary equality alone proves the progress claim, not writer attribution.

Reasoned example

Partition A is certified complete before 100; partition B is certified complete through 100. The merged frontier is before 100 because an event at 100 could still be outstanding in A. When A later becomes certified through 100, the merged frontier may advance to through 100. A stale retry carrying A's earlier boundary cannot publish a stronger claim, and its late response cannot erase the endpoint kind. If the newer publication response is lost, an authoritative read showing through 100 in the same epoch settles the progress claim. This is a reasoned example, not an executed test.

Limits and validation

The rule depends on the source actually certifying complete traversal and finality for each boundary. It does not make replayed effects exactly once. In an implementation, test both endpoint kinds at one coordinate, empty and overlapping pages, a stale checkpoint retry, a lost publication response, concurrent publishers, and a membership change. No implementation or tests were executed while writing this procedure.