@TCK_User1 thanks for your patience while I took some time to investigate this and review prior reports. I’ve been able to reproduce the behavior you’re seeing: when using sort_by=modified_at, the Task Search API returns results where some tasks appear out of order relative to the modified_at value returned in the JSON.
Also, to add to your observation, this isn’t limited to items near page boundaries, it can occur anywhere in the response.
The underlying reason is that there are effectively two “modified” concepts associated with a task: one which reflects the last time the object was updated in the database and a separate reflecting changes that are visible in the Asana UI (as described in the earlier post).
On your questions:
1) Is the Search API guaranteed to return results strictly ordered by
modified_atwhen usingsort_by=modified_at?
Not with respect to the modified_at value returned by the API.
Strict ordering across multiple paginated requests would be impossible to guarantee for a rapidly changing field like modified_at anyway, because tasks are modified while you’re paginating.
2) If not, what is the recommended safe way to paginate when using
modified_at?
It depends on your integration goal, but two approaches come to my mind:
Option A: Add deliberate overlap, de-dupe by task GID
When paginating based on a moving modified_at cursor, fetch the next page with an intentional overlap. Then de-dupe by task GID on your side. That would protect from the “boundary drift”.
Option B: Use “Get multiple tasks” with modified_since, sort client-side if needed
If your goal is incremental sync (“give me everything modified since”), using the task surface endpoint seems more robust to me. You can reliably page through results using stable pagination controls (limit/offset are supported in this context), then sort the final set by consumer-side if needed.
It’s a bit more legwork, but it gives you more deterministic control and avoids the quirks of search indexing (including occasional temporary indexing delays).
- Is this a known issue or something that can be addressed at the API level?
In a sense it’s known behavior. The search backend is sorting, just not necessarily by the exact timestamp seen in the API payload. I agree this can be surprising and is not suitable for pagination logic.