You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems graph-node does not fully support all features of GraphQL schema definition. And defining a schema that's not supported tends to be reported only during the final deploy step instead of build step, which could be misleading and confusing during development.
It would really helpful and saves time if unsupported or invalid schema is reported early during build steps instead of deploy
Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.
No response
Some information to help us out
Tick this box if you plan on implementing this feature yourself.
I have searched the issue tracker to make sure this issue is not a duplicate.
The text was updated successfully, but these errors were encountered:
interfaceCampaign {
id: Bytes! # ... other fields
}
typeERC20CampaignimplementsCampaign@entity {
# Campaign:id: Bytes! # ... other fieldsclaims: [ERC20Claim!]!@derivedFrom(field: "campaign")
}
interfaceClaim {
id: Bytes! # ... other fieldscampaign: Campaign!
}
typeERC20ClaimimplementsClaim@entity(immutable: true) {
id: Bytes! # ... other fields # Extra fields:campaign: ERC20Campaign! # union types doesn't seem supported yet
}
This is an excerpt from what i've been working on. Not exactly sure if this is an invalid GraphQL issue, or graph-node issue tbh. But nevertheless, graph build would be successful without reporting any issues. When doing graph deploy, after completing all the preliminary steps, in the end it fails with the error:
✖ Failed to deploy to Graph node https://api.thegraph.com/deploy/: deployment failure::subgraph resolve error: resolve error: Entity type `ERC20Claim` does not satisfy interface `Claim` because it is missing the following fields: campaign: Campaign!
It would be nice if this could be known at the build step before deploy
@saihaj what do you think ? Is there a way to validate the schema to make sure its supported by graph-node during the build? Although the provided example is valid GraphQL graph-node doesn't support it, is what i understand (?)
Is there a way to validate the schema to make sure its supported by graph-node during the build?
Yeah I think there are some things we can do in graph-cli. I think if we can have meta.graphql in CLI. Based on example this there is probably missing implementing all the fields for the interface and in GraphQL you must redefine all the fields if you are implementing an interface. So we can compose a Schema and then try to get these errors on build time. cc @dotansimha if you have any other ideas on this one
saihaj
transferred this issue from graphprotocol/graph-node
Jun 5, 2023
Description
It seems graph-node does not fully support all features of GraphQL schema definition. And defining a schema that's not supported tends to be reported only during the final deploy step instead of build step, which could be misleading and confusing during development.
It would really helpful and saves time if unsupported or invalid schema is reported early during build steps instead of deploy
Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.
No response
Some information to help us out
The text was updated successfully, but these errors were encountered: