@inaccessible object types within fragment-nested @requires can cause Fed 2 composition to throw

[sachindshinde]

Description
When an object type is @inaccessible and is used in a fragment-nested @requires, it can cause Fed 2 composition to throw. (To be clear, I'm not sure what the root cause is; it may be something else.)

Example
When using @apollo/composition@2.0.2, composing the following two subgraphs will cause composeServices() to throw.

# Subgraph A
extend schema
@link(
  url: "https://specs.apollo.dev/federation/v2.0",
  import: ["@key", "@shareable"]
)

type Query @shareable {
  dummy: Entity
}

type Entity @key(fields: "id") {
  id: ID!
  data: Foo
}

interface Foo {
  foo: String!
}

interface Bar implements Foo {
  foo: String!
  bar: String!
}

type Baz implements Foo & Bar @shareable {
  foo: String!
  bar: String!
  baz: String!
}

type Qux implements Foo & Bar @shareable {
  foo: String!
  bar: String!
  qux: String!
}

# Subgraph B
extend schema
@link(
  url: "https://specs.apollo.dev/federation/v2.0",
  import: ["@key", "@shareable", "@external", "@requires", "@inaccessible"]
)

type Query @shareable {
  dummy: Entity
}

type Entity @key(fields: "id") {
  id: ID!
  data: Foo @external
  requirer: String! @requires(fields: "data { foo ... on Bar { bar ... on Baz { baz } ... on Qux { qux } } }")
}

interface Foo {
  foo: String!
}

interface Bar implements Foo {
  foo: String!
  bar: String!
}

type Baz implements Foo & Bar @shareable @inaccessible {
  foo: String!
  bar: String!
  baz: String!
}

type Qux implements Foo & Bar @shareable {
  foo: String!
  bar: String!
  qux: String!
}

The stacktrace emitted is:

node_modules/@apollo/federation-internals/src/definitions.ts:186
  return type.kind == 'InterfaceType';
              ^
TypeError: Cannot read property 'kind' of undefined
    at isInterfaceType (node_modules/@apollo/federation-internals/src/definitions.ts:186:15)
    at isAbstractType (node_modules/@apollo/federation-internals/src/definitions.ts:250:10)
    at advanceWithOperation (node_modules/@apollo/query-graphs/src/graphPath.ts:1862:27)
    at advanceSimultaneousPathsWithOperation (node_modules/@apollo/query-graphs/src/graphPath.ts:1502:19)
    at ConditionValidationResolver.advanceState (node_modules/@apollo/composition/src/validate.ts:492:65)
    at ConditionValidationResolver.validateConditions (node_modules/@apollo/composition/src/validate.ts:478:30)
    at node_modules/@apollo/composition/src/validate.ts:455:17
    at node_modules/@apollo/query-graphs/src/conditionsCaching.ts:39:26
    at canSatisfyConditions (node_modules/@apollo/query-graphs/src/graphPath.ts:1368:22)
    at advancePathWithDirectTransition (node_modules/@apollo/query-graphs/src/graphPath.ts:1217:33)

[pcmanus]

That issue is actually fixed by the patch in #1873. More precisely, it's the part of the commit there where I said:

There was also another place within query planning (in graphPath.ts more precisely) where the code was looking up the possible implementation types, in the supergraph, of the required @inaccessible type, and was using the supergraph API to do so, which was incorrect for the same reason. This commit fix that problem as well, passing the full supergraph instead.

I've pushed the repro of this ticket as a unit test on that #1873 PR for good measure, but I'll close both this and #1866 when than PR lands.

[pcmanus]

but I'll close both this and #1866 when than PR lands

Well, better late than never.