-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
There can be only one variable named \"$hasura_json_var_1\ #7170
Comments
This is causing us a massive issue, since we have multiple mutations that previously worked that are suddenly broken and we "forced" to use the alpha v10 instead of the latest version. |
BadgeType
Also I connected remote schema inside my hasura and created custom resolver. It is working fine on remote schema url |
We've had some internal discussions about this today. There seems to be an issue with the way the GraphQL queries that are sent to remotes GraphQL servers are built. In particular, there is a phase that tries to come up with fresh GraphQL variables, so that presets for certain object fields can be incorporated. This is essentially what The philosophy of that In this case, the value The above explains why the remote GraphQL server chokes on the query it receives. However, for me there is one additional point of confusion: why did Hasura declare the variable
I believe the answer can be found here. At that point, all we've generated for the GraphQL query we're building, is an (augmented) GraphQL selection set. That particular method generates the list of variable declarations. The particular line linked extracts the desired list of variable declarations from it as follows:
(* The reason this is at best an intuition is that in reality such things are represented in graphql-engine by abstract syntax trees.) The reason that @0x777 suggested that the so-called variable cache should index based on not just JSON values, but also on GraphQL types. I think that's necessary, but I'm not yet fully convinced it's sufficient. The augmented variable usages have a third identifying element, namely a But the duplication problem above could potentially apply, especially if at some point in the future we would for some reason also want to generate optional variables here. So to avoid declaring a variable twice, I think we should also keep track of whether the variable is required or not. Anyway, the last paragraph is not super important to get right, I think. If the so-called variable cache simply indexes both by value and by type, this issue should be avoided. |
I can't able to access this page |
@jemink Thanks, I've updated the links, they should work for you now. |
@jemink Ah, and I realize it perhaps wasn't clear from my phrasing, but indeed this is a bug, and we're fixing it. My message above was simply analyzing what's going on internally inside graphql-engine. |
Hello @abooij |
@jemink A fix is being developed and will be released ASAP. |
Thank you. Please let me know when you released the new version |
Closed via c322af9. |
I upgraded my hasura on below version
hasura/graphql-engine:v2.0.0-beta.2.cli-migrations-v3
And run below query
Variable:-
Then I am getting below error
But it is working fine with alpha 10
The text was updated successfully, but these errors were encountered: