fix(composition): Catch unsatisfiable @shareable
mutation fields
#3305
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes a bug where composition may erroneously declare a schema with a
@shareable
mutation field satisfiable when it shouldn't be.Specifically, this PR updates composition satisfiability to ensure that all query paths under a
@shareable
mutation field can be satisfied starting at the same subgraph. (I.e., that no matter what selection set is on the@shareable
mutation field, the query planner will not need to make multiple calls to that mutation field across subgraphs.)This is done by partitioning subgraph paths in
ValidationState
by the initial subgraph when a shared mutation field is encountered, and keeping track of separate error stacks as well. If all these partitions experience satisfiability errors, then there's no way to satisfy the selection set containing the witness operation from each partition using a single@shareable
mutation field call, and the user is asked to fix (at least) one of the partition's satisfiability errors.This PR may cause composition errors for a previously successful composition if that composition was mistakenly satisfiable due to this bug. We've determined that this may not be a rare occurrence, and accordingly this fix will land in the next minor release (which is why this PR was split off from #3303, where it was originally filed). This PR is currently stacked on top of #3304 for tests to pass, but once that PR merges and is pulled into
next
, this PR's base will change tonext
.