Revert "fix(query-planner): Fix bug where subgraph jump key fields are fetched from the wrong group" (#3300)

Reverts #3293 , as we haven't finished fully testing whether the solution is sound (and we don't want to block any pending releases).

Author: sachindshinde

.changeset/afraid-singers-arrive.md

@@ -3162,126 +3162,6 @@ describe('@requires', () => {
       }
     `);
   });
-
-  it('avoids selecting inapplicable @key from parent fetch group', () => {
-    // Previously, there was an issue where a subgraph jump inserted due to a
-    // @requires field would try (as an optimization) to collect its locally
-    // satisfiable key from the parent, but the parent may not have that locally
-    // satisfiable key. We now explicitly check for this, falling back to the
-    // current node if needed (which should be guaranteed to have it).
-    const subgraph1 = {
-      name: 'A',
-      typeDefs: gql`
-        type Query {
-          t: T
-        }
-        type T @key(fields: "id1") {
-          id1: ID!
-        }
-      `,
-    };
-
-    const subgraph2 = {
-      name: 'B',
-      typeDefs: gql`
-        type T @key(fields: "id2") @key(fields: "id1") {
-          id1: ID!
-          id2: ID!
-          x: Int @external
-          req: Int @requires(fields: "x")
-        }
-      `,
-    };
-
-    const subgraph3 = {
-      name: 'C',
-      typeDefs: gql`
-        type T @key(fields: "id2") {
-          id2: ID!
-          x: Int
-        }
-      `,
-    };
-
-    const [api, queryPlanner] = composeAndCreatePlanner(
-      subgraph1,
-      subgraph2,
-      subgraph3,
-    );
-    const operation = operationFromDocument(
-      api,
-      gql`
-        {
-          t {
-            req
-          }
-        }
-      `,
-    );
-
-    const plan = queryPlanner.buildQueryPlan(operation);
-    expect(plan).toMatchInlineSnapshot(`
-      QueryPlan {
-        Sequence {
-          Fetch(service: "A") {
-            {
-              t {
-                __typename
-                id1
-              }
-            }
-          },
-          Flatten(path: "t") {
-            Fetch(service: "B") {
-              {
-                ... on T {
-                  __typename
-                  id1
-                }
-              } =>
-              {
-                ... on T {
-                  __typename
-                  id2
-                }
-              }
-            },
-          },
-          Flatten(path: "t") {
-            Fetch(service: "C") {
-              {
-                ... on T {
-                  __typename
-                  id2
-                }
-              } =>
-              {
-                ... on T {
-                  x
-                }
-              }
-            },
-          },
-          Flatten(path: "t") {
-            Fetch(service: "B") {
-              {
-                ... on T {
-                  __typename
-                  x
-                  id2
-                }
-              } =>
-              {
-                ... on T {
-                  req
-                }
-              }
-            },
-          },
-        },
-      }
-    `);
-  });
 });
 
 describe('fetch operation names', () => {

query-planner-js/src/__tests__/buildPlan.test.ts

@@ -4814,34 +4814,13 @@ function createPostRequiresGroup(
     // we need the path here, so this will have to do for now, and if this ever breaks in practice, we'll at least have an example to
     // guide us toward improving/fixing.
     assert(parent.path, `Missing path-in-parent for @requires on ${edge} with group ${group} and parent ${parent}`);
-    let requirePath = path.forParentOfGroup(parent.path, parent.group.parentType.schema());
-    let preRequireGroup = parent.group;
-
-    // The `postRequireGroup` needs a key. This can come from `group` (and code
-    // in `canSatisfyConditions()` guarantees such a locally satisfiable key
-    // exists in `group`), but it can also potentially come from `parent.group`,
-    // and previous code had (wrongfully) always assumed it could.
-    //
-    // To keep this previous optimization, we now explicitly check whether the
-    // known locally satisfiable key can be rebased in `parent.group`, and we
-    // fall back to `group` if it doesn't.
-    const keyCondition = getLocallySatisfiableKey(dependencyGraph.federatedQueryGraph, edge.head);
-    assert(keyCondition, () => `Due to @requires, validation should have required a key to be present for ${edge}`);
-    if (!keyCondition.canRebaseOn(typeAtPath(preRequireGroup.selection.parentType, requirePath.inGroup()))) {
-      requirePath = path;
-      preRequireGroup = group;
-      // It's possible we didn't add `group` as a parent previously, so we do so
-      // here similarly to how `handleRequiresTree()` specifies it.
-      postRequireGroup.addParent({ group, path: [] });
-    }
-
     addPostRequireInputs(
       dependencyGraph,
-      requirePath,
+      path.forParentOfGroup(parent.path, parent.group.parentType.schema()),
       entityType,
       edge,
       context,
-      preRequireGroup,
+      parent.group,
       postRequireGroup,
     );
     return {