An order synchronisation can look healthy while missing records around its last checkpoint. Shopify’s 19 October timestamp-filter update identifies a boundary worth testing before an app moves to GraphQL Admin API version 2026-10.
For a timestamp filter using an exclusive lower bound, >, without fractional seconds, that version excludes the entire stated second. Shopify gives the example of an order stored at 12:00:02.500: a bound of 12:00:02 no longer returns it. Earlier versions compared against the start of that second.
Find where the checkpoint comes from
Ask the app owner to locate queries that reuse a timestamp from an earlier response as the next lower bound. Shopify notes that returned timestamps can have second-level precision even when some resources store fractions internally. A saved checkpoint therefore needs scrutiny before it becomes a filter.
Shopify recommends using >= and removing duplicates by ID if the app must include records created later in the same second. Its notice says the other comparison operators, date-only values and explicitly fractional timestamp values are unchanged. Keep the review focused on the affected query shape rather than rewriting every date filter.
Make a boundary test visible
Our suggested acceptance test uses a controlled set of records around the checkpoint. Have the developer document the expected IDs before running the sync. Compare the result with that list, including records within the checkpoint second and just after it.
Test an empty result as well. Decide what the integration should store when no new records arrive and how the next run resumes. A dashboard showing a successful request doesn’t prove that every intended record reached the destination.
These are recommended integration tests, not a claim that Shopify’s notice covers every cause of missed orders. Permissions, pagination and application-specific processing still need their own checks.
Prove that repeated records are safe
If the integration deliberately reads overlapping data, the receiving workflow needs a defined response to a repeated ID. Ask whether it updates the existing destination record, skips it or raises an exception. Then demonstrate that behaviour with the same record twice.
For example, an order export should have an explicit way to avoid creating a second destination order when it reads the same source ID again. Record that rule in the handover. Re-reading data and repeating a business action are separate decisions.
Give the migration an evidence pack
Before changing the API version, keep the old query, proposed query, test IDs and observed results together. Include the version used for each test and the checkpoint stored afterwards. This gives the merchant a way to review a missing-order complaint without relying on memory.
If an agency uses coding assistants while inspecting the integration, our Shopify development article provides related workflow context. Keep the acceptance decision with someone who understands the destination system and can inspect the actual results.
End the review with a reconciled sample: the source records expected in the interval, the records received and any explained difference. Schedule the version change only after the owner can show how the sync handles the boundary and a repeated record.
Author
