The store has an order that the sales system never received, yet the integration reports no failed request. One place to investigate is the boundary used to fetch the next batch. If the application asks for orders strictly later than the last timestamp it saw, it may be treating a displayed second as if it identified a single completed record. Several different orders can share that displayed time.

Shopify's October 19 changelog explains a change in GraphQL Admin API version 2026-10: an exclusive timestamp lower bound without fractional seconds now excludes the whole second. Applications that must include records created later within that second are advised to use an inclusive bound and deduplicate by ID. This concerns a specific incremental-query pattern, not every store or every order integration.

Test the boundary before changing production behaviour

Start by identifying the API version and the actual query. Look for a timestamp taken from a previous response and reused with a greater-than operator. An integration using a different retrieval method may not need this change. Shopify states that applications on version 2026-07 or earlier are unaffected by this update, and the announcement distinguishes other operators and timestamp forms from the changed case.

The underlying difficulty is precision. A timestamp returned to the second can represent records stored internally with fractional seconds. Two orders can therefore show the same createdAt value while remaining distinct objects. Advancing past the entire displayed second can exclude a record the application has not yet handled. A successful request only confirms that the query ran; it does not establish that the chosen boundary covered every intended record.

Construct a test with two different IDs sharing a displayed second and a repeated occurrence of one ID. The distinct orders should both reach the local system. The repeat should be recognised as the same object. This directly tests the boundary and identity assumptions. A broad comparison of daily totals may obscure the problem, particularly if other records arrive or change while the comparison is being made.

Inclusive retrieval deliberately creates overlap

Including the boundary means the application can see a previously processed order again. That overlap is intentional. Remove duplicates using the order's identity, not its timestamp, email address, amount or delivery address. The same buyer can place several orders with similar details, and those purchases should not be collapsed merely because a convenient field happens to match.

The integration must also decide what a repeated record means for local updates. Refreshing the stored representation of an existing order may be appropriate. Creating another sales task or sending another confirmation simply because the record was fetched again is a different action. Keep the object's current state and the completion state of downstream work distinct enough to avoid repeating a business operation during normal overlapping reads.

This matters when an overseas storefront connects to a China-based sales or fulfilment team. The buyer experiences a missing order or a duplicate message, not a timestamp comparison. The teams should therefore test the resulting work as well as the fetched data: both distinct orders arrive, each has the intended local record, and a repeated read does not trigger an additional external action.

Advance progress only over work actually covered

Pagination introduces another boundary. If a batch contains more pages, a poll has not finished merely because its first response succeeded. Do not replace the processing checkpoint with the computer's current time while records remain unread. The checkpoint should represent reliably covered work, rather than the time the synchronisation process most recently started.

Review what happens if execution stops between receiving an order, saving it and triggering follow-up. The right recovery depends on the application's existing design, but it must be explainable. Inclusive retrieval can prevent one form of omission while exposing duplicate actions elsewhere. Changing the comparison operator without examining that sequence can move the fault instead of resolving it.

If the integration has also been offline, old records may create a separate question about whether delayed actions are still appropriate. Our discussion of sales-sync backlogs after a pause addresses that issue. For this API update, keep the change narrower: confirm the affected query, cover the shared-second boundary, preserve distinct order IDs and verify that overlap does not repeat completed work.

Sources