Be strict about error paths format

[martinbonnin]

Replace should with must in the description of error paths: This field must be a list of path segments starting...

    {
      "message": "Name for character with ID 1002 could not be fetched.",
      "locations": [{ "line": 6, "column": 7 }],
      "path": ["hero", "heroFriends", 1, "name"]
    }

Anything else will make it impossible to handle errors in error-aware clients. This is especially important for strict-nullability or semantic-non-nullability

[netlify]

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	88d99e5
🔍 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.

[benjie]

This is technically a breaking change; but it seems more of a bugfix to me - this should (haha) have been a must all along, and I'm not aware of any implementation that is breaking these rules. I'm not going to mark this as an approval until we've discussed at the WG, but I am heavily in favour of it.

@leebyron Was this deliberately a should, or was it a case where natural language accidentally made its way in rather than RFC2119 language?

@martinbonnin Please add this to an upcoming WG for discussion.

cc @graphql/implementers - is anyone's implementation going to break if we change this from should to must?

[captbaritone]

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.

[mjmahone]

@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.

[leebyron]

@graphql/implementers - please review before we accept

[leebyron]

Radiating intent here (and action item): We intend to accept this and merge it next month barring any feedback.

[andimarek]

From a GraphQL Java POV we are ok with that

[mjmahone]

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!