…health-check (#9134)

* fix(graphql): trace resolvers reached through unions and interfaces

The resolver-wrapping traversal only descended through lists and non-nulls, so
it never reached object types referenced solely as union members or interface
implementations. graphql resolves the concrete type at runtime, so an Apollo
Federation subgraph (whose entity types are reachable only through the synthetic
`_Entity` union returned by `_entities`) produced no graphql.resolve spans for
those fields.

Descend into union members via getTypes() and interface implementations via
schema.getPossibleTypes(), keyed off the realm-agnostic `Symbol.toStringTag`
discriminator so an interface without an explicit resolveType is still covered.
patchedTypes keeps the walk one-time per type, so cyclic abstract types
terminate and there is no per-resolve cost.

Fixes: #1057

* fix(graphql): skip the Apollo Federation health-check operation

Apollo Gateway's polling subgraph health check sends a fixed
`query __ApolloServiceHealthCheck__ { __typename }` on every poll interval,
burying real traffic under health-check noise. Skip that named operation by
exact name before span creation. The skip is unconditional because the name is
spec-reserved (the `__` prefix) and the operation carries no user input, so
there is nothing for AppSec or IAST to inspect and no legitimate operation to
collide with. The gateway's other probe, the anonymous startup
`{ __typename }` query, is left alone on purpose: it fires only on startup and
schema update, so it is not a source of recurring noise.

Fixes: #1057

* fix(graphql): harden federation health-check skip and interface walk

1. The health-check skip matched the reserved operation name alone. Since
   operation names are client-controlled, a request naming itself
   `__ApolloServiceHealthCheck__` while selecting a real field (or using a
   mutation, or adding selections beside `__typename`) was silently dropped
   from tracing and from the AppSec/IAST resolver channels. Confirm the
   gateway's exact spec-fixed shape (`query __ApolloServiceHealthCheck__
   { __typename }`) before skipping so the reserved name can't become a
   tracing/security bypass.
2. `getPossibleTypes` is schema-specific, but the interface-implementation
   descent shared the global `patchedTypes` guard. Two schemas reusing one
   interface instance meant the first schema's walk marked the interface and
   the second schema's implementations were never wrapped, so their resolvers
   went untraced. Key the interface descent per (schema, interface) instead.

* fix(graphql): wrap resolvers per schema when types are shared

The resolver-wrapping walk terminated on a global per-type guard, but the
walk is schema-dependent: union members and interface implementations are
read through the schema (getTypes / getPossibleTypes) and differ between
schemas. Two schemas sharing any type on the path to an abstract type — a
reused root Query, a shared interface — meant the first schema's walk marked
that type, and the second schema's walk returned at it before reaching its
own members or implementations, leaving those resolvers untraced.

Key the walk's visited set per (schema, type) so each schema runs its own
full traversal. Resolver wrapping is already idempotent via patchedResolvers,
so re-walking a type shared across schemas never double-wraps a resolver.

Fixes: #1057

* fix(graphql): skip parse and validate spans for the health-check

The health-check skip only suppressed the execute and resolver spans, so a
gateway poll still emitted graphql.parse and graphql.validate. graphql runs
both before execute, so every cold poll (and every poll on servers without a
document cache, e.g. graphql-yoga) left two heartbeat spans a customer's
operation filter would flag.

Detect the poll from the raw query string at parse — the only input parse has —
and mark the produced document so validate and execute skip it too. Apollo
Server caches parsed+validated documents in its documentStore and reuses the
same document object across polls, so a warm poll reaches execute with the
already-marked document; when a health-check document reaches execute without
ever passing through the instrumented parse (pre-populated cache, hand-built
document), the operation-shape check remains the backstop.

Fixes: #1057

* fix(graphql): require exact Apollo health-check documents

Health-check operation names and parsed documents are caller-controlled. Requiring Apollo's complete constant shape keeps transformed or multi-operation documents, and operations with variables or directives, on the traced AppSec and IAST path.

…health-check (#9134)

* fix(graphql): trace resolvers reached through unions and interfaces

The resolver-wrapping traversal only descended through lists and non-nulls, so
it never reached object types referenced solely as union members or interface
implementations. graphql resolves the concrete type at runtime, so an Apollo
Federation subgraph (whose entity types are reachable only through the synthetic
`_Entity` union returned by `_entities`) produced no graphql.resolve spans for
those fields.

Descend into union members via getTypes() and interface implementations via
schema.getPossibleTypes(), keyed off the realm-agnostic `Symbol.toStringTag`
discriminator so an interface without an explicit resolveType is still covered.
patchedTypes keeps the walk one-time per type, so cyclic abstract types
terminate and there is no per-resolve cost.

Fixes: #1057

* fix(graphql): skip the Apollo Federation health-check operation

Apollo Gateway's polling subgraph health check sends a fixed
`query __ApolloServiceHealthCheck__ { __typename }` on every poll interval,
burying real traffic under health-check noise. Skip that named operation by
exact name before span creation. The skip is unconditional because the name is
spec-reserved (the `__` prefix) and the operation carries no user input, so
there is nothing for AppSec or IAST to inspect and no legitimate operation to
collide with. The gateway's other probe, the anonymous startup
`{ __typename }` query, is left alone on purpose: it fires only on startup and
schema update, so it is not a source of recurring noise.

Fixes: #1057

* fix(graphql): harden federation health-check skip and interface walk

1. The health-check skip matched the reserved operation name alone. Since
   operation names are client-controlled, a request naming itself
   `__ApolloServiceHealthCheck__` while selecting a real field (or using a
   mutation, or adding selections beside `__typename`) was silently dropped
   from tracing and from the AppSec/IAST resolver channels. Confirm the
   gateway's exact spec-fixed shape (`query __ApolloServiceHealthCheck__
   { __typename }`) before skipping so the reserved name can't become a
   tracing/security bypass.
2. `getPossibleTypes` is schema-specific, but the interface-implementation
   descent shared the global `patchedTypes` guard. Two schemas reusing one
   interface instance meant the first schema's walk marked the interface and
   the second schema's implementations were never wrapped, so their resolvers
   went untraced. Key the interface descent per (schema, interface) instead.

* fix(graphql): wrap resolvers per schema when types are shared

The resolver-wrapping walk terminated on a global per-type guard, but the
walk is schema-dependent: union members and interface implementations are
read through the schema (getTypes / getPossibleTypes) and differ between
schemas. Two schemas sharing any type on the path to an abstract type — a
reused root Query, a shared interface — meant the first schema's walk marked
that type, and the second schema's walk returned at it before reaching its
own members or implementations, leaving those resolvers untraced.

Key the walk's visited set per (schema, type) so each schema runs its own
full traversal. Resolver wrapping is already idempotent via patchedResolvers,
so re-walking a type shared across schemas never double-wraps a resolver.

Fixes: #1057

* fix(graphql): skip parse and validate spans for the health-check

The health-check skip only suppressed the execute and resolver spans, so a
gateway poll still emitted graphql.parse and graphql.validate. graphql runs
both before execute, so every cold poll (and every poll on servers without a
document cache, e.g. graphql-yoga) left two heartbeat spans a customer's
operation filter would flag.

Detect the poll from the raw query string at parse — the only input parse has —
and mark the produced document so validate and execute skip it too. Apollo
Server caches parsed+validated documents in its documentStore and reuses the
same document object across polls, so a warm poll reaches execute with the
already-marked document; when a health-check document reaches execute without
ever passing through the instrumented parse (pre-populated cache, hand-built
document), the operation-shape check remains the backstop.

Fixes: #1057

* fix(graphql): require exact Apollo health-check documents

Health-check operation names and parsed documents are caller-controlled. Requiring Apollo's complete constant shape keeps transformed or multi-operation documents, and operations with variables or directives, on the traced AppSec and IAST path.