Collection query: only one of "first" and "last" may be provided ( or "before"/"after")

[artalat]

Describe the bug We are using a third-party list component in our project that uses a single graphql query. Seems to be impossible to use with Supabse because we get the following error even if only first is given and last is undefined.

To Reproduce

Im using a basic Todo API example here.

Query:

query TasksCollectionQuery(
  $completed: Boolean!
  $first: Int
  $last: Int
  $before: Cursor
  $after: Cursor
) {
  tasksCollection(
    filter: { completed: { eq: $completed } }
    first: $first
    last: $last
    before: $before
    after: $after
  ) {
    edges {
      node {
        id
        title
        completed
      }
    }
    pageInfo {
      endCursor
      hasNextPage
      hasPreviousPage
      startCursor
    }
  }
}

Query Variables (Notice there is no last property):

{
  "first": 10
}

Response:

{
  "data": null,
  "errors": [
    {
      "message": "only one of \"first\" and \"last\" may be provided"
    }
  ]
}

Expected behavior API should return data and not throw error, since only first is provided.

Screenshots N/A

Versions: Public hosted version

Additional context None.

[olirice]

thank you, I was able to reproduce

in the short term, separating forward and backward pagination queries should avoid the error message

[cspecter]

We are also getting this error: "only one of \"before\" and \"after\" may be provided". It seems like we should be able to use both in one query. Correct? Otherwise how do we implement pull to refresh?

[olirice]

GraphQL queries are more flexible than prepared statements in that you can control things like result ordering via a variable. The first time a query is executed the query builder creates a SQL prepared statement that takes the GraphQL variables as a parameter.

Once that prepared statement is created, some aspects of the query must stay static (like the order by clause). Re-using prepared statements is important because it removes the overhead of the pg_graphql query builder and the postgres query planner from requests.

Some combinations of variables (first/last and (before/after) interact with clauses we need to remain static and are blocked to guarantee our ability to re-use the prepared statement. I'm aware that this is surprising behavior and have a refactor underway that will resolve this + a few other limitations of the current implementation.

Landing that refactor could be a few months away, so in the meantime, please use the workaround of separating forward and backward pagination queries

Sorry that you bumped into this issue. It's significant and it will get resolved

@cspecter

[olirice]

this issue was resolved by #221 and is live on the supabase platform and docker images