graphql-engine: [v2.0.7-cloud.2] order_by not working

Update: We have identified the root cause of this issue and we’ll be making a release on cloud with the fix very soon

Update: We have identified the root cause of this issue and we’ll be making a release on cloud with the fix very soon

@rikinsk - many thanks, you guys are jumping on this and we see and appreciate that deeply. Many thanks.

I work on the same team as @lukeomalley and another question we have around this is can we disable/disallow/opt-in/opt-out of auto “upgrades”?

For production environments, version locking is critical for reliability. Bugs happen, even the best tested software, it is not a very desirable function to silently change your tenants’ version even if you think it’s an “upgrade” or a “fix”. Usually it works and isn’t noticed but this issue highlights the problem with that approach.

I think the only even remotely reasonable exception for changing anything about the code of our runtime would be a very, very severe, massive security or data integrity zero-day that had data loss or theft or security escalation implications, and even then, we should be notified of that upgrade immediately, and auto-upgrade should NOT be the default by any means.

We are experiencing the same issue on v2.0.7-cloud.2.When passing either an array of objects or a plain object the results are not sorted.

@rikinsk Here is our query that is not respecting the order_by clause:

subscription SUBSCRIBE_TO_COMMENTS_BY_IDENTITY_ID(
    $identityId: Int!
    $limit: Int!
    $logTypes: [String!]!
  ) {
    Comments(
      where: {
        identity_id: { _eq: $identityId }
        author_id: { _is_null: false }
        ActivityLogType: { type: { _in: $logTypes } }
      }
      order_by: [{ created_at: desc }]
      limit: $limit
    ) {
      id
      text
      timestamp
      created_at
      updated_at
    }
  }

Closing this as the fix was released in v2.0.7-cloud.3

on the issue of the Array vs. Property Map order_by value, the query validator should throw an error or at least a warning (using the graphql extensions object as I highlighted above) to users who submit anything but an array.

Our decision to not throw an error for such queries was because such queries were supported in v1 and we didnt want to start throwing errors for queries that used to work earlier. Results with bad ordering seemed more acceptable than outright errors in case someone had missed updating their existing queries before updating to v2.0.

But your point is valid. Maybe a Warning in some form seems like the best option here. We’ll discuss this as well to improve the experience around this

This indeed seems to be a bug. We’ll investigate and get back to you soon.

@24601 I guess that was a poor choice of words from my end based on my understanding of the issue. I should have been more clear. Apologies.

What I actually meant by the “random coincidence” was that as the GraphQL spec mentions that entries in an object are unordered, when you pass the following argument order_by: {created_at: asc, user_id: asc} the choice of which field gets picked first can be random. In some instances the created_at will be used to sort first but it is possible in the next iteration user_id might be used to sort first. According to the spec there is no guarantee of consistency here. As this change was introduced since v2.0.0, I meant that possibly while using v2.0.5 created_at was probably getting picked first as a random coincidence. Hope this clarifies what I meant.

⚠️ Also my chat messages are jumping randomly now… something is completely broken in the new cloud version! ⚠️ They have been working fine forever, just order_by created_at.