-
Notifications
You must be signed in to change notification settings - Fork 45
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
Fix validation stack overflow for fragment cycles inside nested fields #733
Conversation
Previously fragment cycle detection only counted fragments that are directly recursive, where the top-level selection for the fragment included a fragment spread of itself. But spreading a fragment anywhere inside a nested field is also problematic and prohibited by spec, because even if the field you're spreading into is nullable, the client can't know how deep that recursion goes, and it could be infinite. Fixes #716
│ ───────┬────── | ||
│ ╰──────── recursive fragment definition | ||
│ | ||
15 │ fragment fragC on Human { name, ...fragA } | ||
16 │ fragment fragC on Human { name, ...fragA } | ||
│ ────┬─── | ||
│ ╰───── refers to itself here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "refers to itself" message should probably be tweaked
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the diagnostic even contain a Vec
of locations to show the complete cycle?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The label is additional context for the error on the fragA
definition, but I agree that it looks a bit odd. Maybe labeling every spread in the cycle and a tweaked message would be ideal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is easy to do currently. would be helpful to have more context lines :/
Error: `cycle` fragment cannot reference itself
╭─[q.graphql:9:1]
│
9 │ fragment cycle on __Type {
│ ───────┬──────
│ ╰──────── recursive fragment definition
│
11 │ ...frag
│ ───┬───
│ ╰───── `cycle` references `frag` here...
│
17 │ ...cycle
│ ────┬───
│ ╰───── `frag` circularly references `cycle` here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be ideal here if, in TTY formatting, cycle
in the final label uses the same colour as fragment cycle
in the primary label 🙈
Previously fragment cycle detection only counted fragments that are
directly recursive, where the top-level selection for the fragment
included a fragment spread of itself. But spreading a fragment anywhere
inside a nested field is also problematic and prohibited by spec,
because even if the field you're spreading into is nullable, the client
can't know how deep that recursion goes, and it could be infinite.
Fixes #716