Graphql-engine: Intermittent error when querying a remote schema joined graphQL field.

[cozmo]

Given the following graphql query

query myQuery($param1:String!, $param2: String!) {
  my_table {
    id
    name

    externallyJoinedField(other_param_1: $param1, other_param_2: $param2) {
      external_field_1
      external_field_2
    }
  }
}

made with the following variables (for posterity, however the values do not matter)

{
  "param1": "p1",
  "param2": "p2"
}

where externallyJoinedField is a remotely joined field, the query (for me at least) fails intermittently (~50%?) with the following error:

{
  "errors": [
    {
      "extensions": {
        "path": "$.variableValues",
        "code": "validation-failed"
      },
      "message": "unexpected variables: param2, param1"
    }
  ]
}

Once it fails, it _seems_ like reloading the metadata resolves the issue for...some amount of indeterminate time. Otherwise continuing to query with the same query will sometimes work again.

At first I was worried that remote joins didn't support a field that had more arguments than the values provided by hasura to join on. However, even if that is true (which would be unfortunate) the main concern for me here is the intermittent nature of this behavior, which would imply to me that whatever it is, is not supposed to happen. Would love to know the expected behavior here, and what would cause this error.

Details

Version - v1.3.1
Metadata.yml:

version: 2
tables:
- table:
    schema: public
    name: my_table
  remote_relationships:
  - definition:
      remote_field:
        external_field:
          arguments:
            id: $id
      hasura_fields:
      - id
      remote_schema: remote-schema
    name: externallyJoinedField
remote_schemas:
- name: remote-schema
  definition:
    url: http://host.docker.internal:3099/graphql
    timeout_seconds: 60

Remote Schema Graphql Schema

type ExternalType {
  external_field_1: String!,
  external_field_2: String!
}

type Query {
  external_field(
    id: String!
    other_param_1: String!
    other_param_2: String!
  ): [ExternalType!]
}

I know this is a weird issue, and it's very possible I've done something weird on my end that's causing this, but I tried to isolate the configuration down to be as simple as possible, and am still able to trigger this. If there's more information I can provide to help debug or reproduce please let me know.

[cozmo]

This is currently effecting our production hasura instance and blocking feature development, I'd love a better sense of the process to getting this issue resolved. I'd be happy to help create a fix, or debug it it in more depth, or pay for premium support, etc, but not even sure where to start. Any help/suggestions for next steps would be much appreciated.

[MinJunKimKR]

I think, externallyJoinedField(other_param_1: $param1, other_param_2: $param2) this part is wrong.

I guess, you missed _eq . so pram should be like {_eq : $param1}.

[cozmo]

Hmm, @MinJunKimKR, that'd be surprising to me. As I understand it, _eq is a param that hasura exposes in the resolvers for tables it manages. For the external schemas, hasura (I think) just directly exposes the underlying graphql schema, without any changes. At least this has been my experience with external schemas up until this point. As you can see in my remote graphql schema above, the external_field doesn't expose _eq, but rather some params directly. As such, I'd expect you'd pass them directly when interacting with the remote joined field.

This is backed up by the fact that the graphql schema, when querying hasura with an introspection query, as well as when interacting with the graphql editor in the hasura console both (correctly) have these params directly on the remote field, vs any _eq param.

Additionally, the fact that this query only fails intermittently to me implies that the query itself isn't incorrect, but rather there's some sort of issue executing it. However maybe I misunderstand something?

[tirumaraiselvan]

@cozmo We are investigating this.

[tirumaraiselvan]

This is happening because of an edge case in the query plan caching module.

The workaround could be to disable the query plan caching entirely by setting the env var: HASURA_GRAPHQL_QUERY_PLAN_CACHE_SIZE=0 . Note that this will affect the performance of your queries, it will be equal to the first time you run a query after a fresh start of hasura.

In v1.4, we have removed this module as the performance benefits were not significant when combined with the query parsing refactors which are introduced in v1.4. So this should get automatically solved in v1.4.

[cozmo]

Thanks for the information. Is the performance hit of setting HASURA_GRAPHQL_QUERY_PLAN_CACHE_SIZE=0 worse or equal to the performance of 1.4 with the query cache module removed?

[tirumaraiselvan]

v1.4 performance (without query plan caching) is equal to v1.3 (with query plan caching enabled) for queries that are not heavily nested (5+ levels).

We may introduce query plan caching in v1.4 later as well.

[tirumaraiselvan]

Closing this as dupe of https://github.com/hasura/graphql-engine/issues/5557