Repair Sorting Stability, Tie-Break & Pagination Bugs

FAULT BOUNDARY IDENTIFIED

Case analyzed

An orders screen sorts by created_at DESC and uses cursor pagination. Many orders share the same second-level timestamp, so moving to page two sometimes repeats or skips orders. The cursor contains only created_at.

The supplied facts are sufficient to perform a concrete repair diagnosis for this case. No repository, production, vendor, or legal access is assumed.

Verified evidence

• VERIFIED: The list sorts by created_at DESC.
• VERIFIED: Many orders share the same timestamp.
• VERIFIED: The cursor stores only created_at.
• VERIFIED: Users see duplicates and omissions between pages.

Concrete findings

1. created_at alone is not a total order because multiple orders share the same timestamp; the cursor cannot identify a unique continuation point.
2. Use a deterministic tie-break such as order_id and keep direction consistent: created_at DESC, order_id DESC, with both values in the cursor.
3. The cursor predicate must match the sort tuple, not merely serialize the second field.
4. The directory case also requires explicit null ordering and production-equivalent collation in tests.

The canonical acceptance rule is

A paginated sort is stable only when the ordering defines a deterministic total order, tie-break fields are included consistently in queries and cursors, and null/collation behavior does not change between pages or execution environments.

The current result is based on that invariant, not on a generic success banner or a reusable checklist.

Required actions

Primary Sort Semantics: repair the owning boundary and preserve this case as a regression fixture; record the exact acceptance condition and owner.
2. Deterministic Tie-Break Key: repair the owning boundary and preserve this case as