Closed martinbonnin closed 7 months ago
Name | Link |
---|---|
Latest commit | 88d99e550b39c29c611989928fd53c9407d1d00b |
Latest deploy log | https://app.netlify.com/sites/graphql-spec-draft/deploys/65bbef231a82d50009549022 |
Deploy Preview | https://deploy-preview-1073--graphql-spec-draft.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
cc @mjmahone in case you have context on why this is not "must". You mentioned that this might have been an intentional choice to allow servers to use errors to silently handle things like permissions?
I can see a parallel here with things like returning 404 errors when you try to access a route that you don't have permission to view in order to prevent you from using the status code to determine if a private entity exists or not.
@captbaritone I was misunderstanding the context. I don't have an objection to the path
being required to be a list of strings/ints if it exists.
@graphql/implementers - please review before we accept
Radiating intent here (and action item): We intend to accept this and merge it next month barring any feedback.
From a GraphQL Java POV we are ok with that
At the Mar 7 WG meeting we established that we intend to merge this PR after the April WG meeting, unless there are objections.
If you implement a GraphQL server or client and do not implement the error paths array as specified, please let us know!
Replace
should
withmust
in the description of error paths:This field must be a list of path segments starting...
Anything else will make it impossible to handle errors in error-aware clients. This is especially important for strict-nullability or semantic-non-nullability