Unexpected ordering behavior after scheduled publish transitions

🆘 Support
1

Hi Dato team,

I’m running into an odd ordering issue related to publish times and the orderBy query filter. I recorded a Loom walking through the behavior, and wanted to summarize the workflow here as well.

I created a Dato demo environment and added an Order (number) field to the BlogPost model. The problem appears when a scheduled publish transitions into an actual publish, specifically around a date change.

For example, our API timezone is US Eastern. If posts are scheduled to publish at 12:01 AM EST (00:01), the moment they go live _publicationScheduledAt becomes null, and _firstPublishedAt becomes equal to _publishedAt as expected.

However, based on our sorting rule, the results should then fall back to the order field, but that does not happen.

Here’s the orderBy configuration we are using:

orderBy: [
  _firstPublishedAt_DESC,
  _publicationScheduledAt_DESC,
  order_ASC,
  _createdAt_DESC,
  id_DESC
]

Once published, we would expect all three posts to sort by order_ASC, but instead the results remain sorted by their publish time.

I was able to reproduce the issue in this environment:
https://demo-4567.admin.datocms.com
I can invite anyone to access if needed.

Query and result shown below:

{
  allPosts(
    filter: { order: { exists: true } }
    orderBy: [
      _firstPublishedAt_DESC,
      _publicationScheduledAt_DESC,
      order_ASC,
      _createdAt_DESC,
      id_DESC
    ]
  ) {
    id
    title
    _publishedAt
    _firstPublishedAt
    _publicationScheduledAt
    order
  }
}


{
  "data": {
    "allPosts": [
      {
        "id": "UiKgiPoZTsesocwVHk3gtg",
        "title": "Autopublish 3",
        "_publishedAt": "2025-12-05T00:01:00-05:00",
        "_firstPublishedAt": "2025-12-05T00:01:00-05:00",
        "_publicationScheduledAt": null,
        "order": 3
      },
      {
        "id": "Dr40xxUGRNqOIiFclfHqfQ",
        "title": "Autopublish 2",
        "_publishedAt": "2025-12-05T00:01:00-05:00",
        "_firstPublishedAt": "2025-12-05T00:01:00-05:00",
        "_publicationScheduledAt": null,
        "order": 2
      },
      {
        "id": "WCvr_A4OSlqBHPsqsZhhnw",
        "title": "Autopublish 1",
        "_publishedAt": "2025-12-05T00:01:00-05:00",
        "_firstPublishedAt": "2025-12-05T00:01:00-05:00",
        "_publicationScheduledAt": null,
        "order": 1
      }
    ]
  }
}

Please let me know if this makes sense or if I can provide any additional context, happy to help however I can!

2

Hi @danny,

Thanks very much for the clear description and sample queries! It really helps to make sense of the problem.

This does look like an issue on our side (sorry!). Let me report it to the devs for you and let you know once it’s resolved.

4

@danny,

I have a hypothesis. I think this might be due to millisecond truncation in the CDA. They all look like 2025-12-05T00:01:00, but if you use the CMA (our REST API, also used by our UI), you can see that they are actually published a few milliseconds apart:

Blog Post collection Content Demo DatoCMS - 2025-12-05 09-53-52 AM
Blog Post collection Content Demo DatoCMS - 2025-12-05 09-53-52 AM1720×1326 362 KB

It looks like the GraphQL layer is showing you the truncated time without milliseconds, but actually still sorting by the milliseconds version — that’s why the fallback isn’t working; they are actually off by just a few ms.

I’ve reported this to the devs already and will update you as soon as I can.

In the meantime, if you need a workaround, perhaps you can do the sorting on the frontend for the time being?

5

@roger

Thanks for your message and the hypothesis! From a glance that really feels like it could be the issue, eager to hear what the devs uncover.

No worries on a work around, scheduling the publishing to be a minute apart seems to do the trick.

1 Like
6

Genius! :brain: :100:

I’ll let you know once it’s fixed.

7

@danny,

A dev confirmed that this is indeed a milliseconds issue. Internally (and with our REST CMA API) we use millisecond precision, but we truncate that for the CDA (GraphQL API) to increase cache hits.

Unfortunately, in your particular case, that does create fallback sort order issues =/

The fix isn’t super trivial, because we have to ensure we don’t break any existing uses.

We are currently evaluating a potential opt-in flag for the CDA that will allow customers to choose to see millisecond precision in the CDA as well. We considered a few options, but this seems the least likely to break backward compatibility for existing users. We’ll let you know if that gets done!

1 Like