Carry every eligible record across a timed handover

A timestamp is useful for ordering work. It is not always enough to identify the point where a batch should continue. Two requests can have the same recorded time, and a handover that remembers only that time can quietly leave one behind.

The problem is easy to miss when a review looks only at the first page or a total produced by the same faulty query. A useful investigation compares the eligible records with the actual records delivered, then examines how the next batch is selected.

Define the handover before investigating it

In this fictional Nigerian training-office example, a coordinator prepares a fixed set of five eligible enquiries for a staff handover. The export is authorised for that team. The application supports a stable snapshot S-8 and orders its records by the stored UTC creation instant, then by a unique numeric enquiry identifier. These are inspected capabilities of the example, not assumptions about every provider's API.

The approved task is to deliver each member of S-8 once. Enquiries arriving later belong to a subsequent handover. That rule keeps the investigation focused: it does not require a running export to chase a changing live collection.

The five eligible records are:

The UTC notation identifies the stored instants explicitly. Staff-facing displays can use the agreed local zone, but a display conversion cannot separate 302 and 303: their recorded instants are equal. Their distinct enquiry identities are essential to the continuation rule.

Reproduce the missing record

The batch size is two. The first batch returns 301 and 302. The faulty continuation stores only 08:15:00Z and asks for records whose creation time is later than that value. It therefore returns 304 and 305. Enquiry 303 is eligible but never reaches the receiving file.

Increasing the batch size might hide this particular failure by placing both tied records in the same batch. It would leave the rule vulnerable at a different boundary. Changing the timestamp of 303 would damage the source evidence merely to make pagination convenient.

The reviewer compares the two delivered identifier lists with S-8: expected 301, 302, 303, 304, 305; observed 301, 302, 304, 305. The missing identity explains the discrepancy independently of any displayed total. Each exported record's substantive fields are also checked so that a repeated row cannot stand in for the absent one.

Continue after a position, not just an instant

The supported correction remembers the last complete ordering key: creation instant plus unique enquiry identifier. After 302, the next query includes a row if its time is later, or if its time is equal and its identifier is greater than 302. It uses the same two-field ascending order and the same S-8 membership.

The corrected batches are therefore 301/302, then 303/304, then 305. Enquiry 303 is included because it comes after 302 in the declared tie order. Enquiry 302 is not repeated because the continuation is strictly after the complete position.

PostgreSQL's ordering documentation explains that later sort expressions distinguish rows equal under earlier expressions. The example applies that principle to an explicitly defined continuation contract. A real implementation must use its actual database or provider's supported cursor, ordering, null handling and snapshot behaviour; an arbitrary token assembled by the browser is not a substitute for that contract.

The unique identifier here is numeric, non-null and stable within S-8. If an actual system uses text identifiers, mutable ordering fields or an opaque provider cursor, inspect those semantics rather than assuming the same comparison is appropriate.

Test the boundary and an ordinary batch

The reviewer runs the corrected S-8 export with batch size two and reconciles all five identities, their order and their field contents. Each appears once. A batch size of three produces the same final membership, even though the page boundaries differ. A batch size large enough for the entire set also agrees.

An empty eligible set completes without inventing a row. A separate snapshot containing two records at different times follows the normal order. These checks show that the repair addresses tied boundaries without making ordinary exports depend on a special-case fixture.

The reviewer then adds a later-arriving enquiry outside S-8. It does not appear halfway through the existing handover. A separately authorised S-9 can include it under the office's stated next-run policy. That is a test of the agreed membership boundary, not permission to discard late work. The coordinator's procedure must identify how the next handover is opened and reconciled.

Make the receiving evidence usable

The handover record names S-8, its eligibility rule, the complete ordering key, export identity and reconciled enquiry identifiers. The recipient can distinguish a complete export from a partial run. If delivery stops, any supported continuation resumes from the last confirmed position under the same snapshot contract; it does not guess from the last time printed on a screen.

The responsible team also needs to know how long a snapshot or provider cursor remains valid. An expired continuation may require a new, explicitly reconciled export. Reusing an invalid cursor or silently mixing memberships would be a different failure from the one repaired here.

Use the request map to name the receiving team and the evidence it expects. The work-queue service can then scope how eligible work is selected, transferred and accounted for without turning every timestamp into an assumed unique identity.