graphql-engine: Incorrect LIMIT behaviour in v2.1.0

Version Information

I’ve upgraded graphql-engine from v2.0.10 to v2.1.0.

Environment

Google Cloud Platform: Kubernetes Engine

What is the current behaviour?

Memory usage grows over time (possible memory leak)

Screenshots or Screencast

image

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 22 (19 by maintainers)

Most upvoted comments

@maxpain Really sorry for the delay here. We did triage this internally but missed to update here.

There are 2 aspects to the current “bug”:

  1. The issue only happens for a manual object relationship. Object relationships are typically meant for a n:1 or a 1:1 relationship i.e. the right hand side relation returns at max one row for a given left hand side row. But, in your case there are multiple rows on the right hand side for the same row. In older versions of Hasura, this would return any one row (randomly selected) for the relationship. It’s not clear if this is intentional since an array relationship would be better suited here.

  2. We will fix the behaviour to return a single randomly selected row in such a scenario (older behaviour) soon. But the priority of this is not urgent since this is a rather unexpected configuration.

Thanks, pasting repro artifacts here:

metadata.json.txt dump.sql.txt

Query (with user role or admin role):

{
  users(
    where: {id: {_eq: 1}}
    limit: 1
  ) {
    id
    isMeBlacklisted {
      targetUserID: target_user_id
    }
  }
}

Result (wrong):

{
  "data": {
    "users": [
      {
        "id": 1,
        "isMeBlacklisted": {
          "targetUserID": 2
        }
      },
      {
        "id": 1,
        "isMeBlacklisted": {
          "targetUserID": 3
        }
      }
    ]
  }
}

@jberryman I’ve sent you explain analyze results of the same query running on v2.1.0 against v2.0.10

Are you able to do an EXPLAIN ANALYZE?

Yes, I will compare generated SQL queries and do EXPLAIN ANALYZE on both v2.1.0 and v2.0.10 versions on the same dataset.

And did 13:00 represent a deployment of new application code or anything else?

No

Or was the hasura version the only thing that changed?

Yes

Gotcha, can you share a few of those newly-slow queries with us privately please? (like the green and red bands from the “Total query time” graph) brandon@hasura.io

If you’re able to do an EXPLAIN ANALYZE against your db for those, that would be helpful as well. If you can share a db dump with row data removed and your hasura metadata that also is helpful.

Done