This project adheres to Semantic Versioning v2.0.0.
expand_json_string_values option to JSON log formatter (PR #9156)When expand_json_string_values: true is set on a stdout or file JSON log formatter, string attribute values that contain valid JSON objects or arrays are emitted as native JSON instead of quoted strings. This enables log aggregators like Splunk to index sub-fields such as errors{}.extensions.code.
This is useful when telemetry selectors like response_errors: "$[*]" produce structured data: OpenTelemetry's attribute model serializes objects to JSON strings, but log formatters can now expand those strings back to native JSON at emit time. OTLP exporters are unaffected.
By @carodewig in https://github.com/apollographql/router/pull/9156
supergraph.path to support queries with and without trailing slashes (/) (PR #8860)Normalize trailing / for supergraph.path to support /graphql and /graphql/. This works by stripping trailing / from both the configured path and the incoming query path to ensure they match, regardless of whether the config or query includes a trailing slash.
By @Jephuff in https://github.com/apollographql/router/pull/8860
exp on a per-JWKS basis while still rejecting expired tokens (Issue #8910, PR #8911)Adds a per-JWKS allow_missing_exp configuration option to Router JWT authentication. When enabled for a JWKS entry, tokens without an exp claim are accepted for that JWKS. Tokens that include an exp claim continue to be validated and rejected if expired.
This is useful for deployments that rely on long-lived machine-to-machine or service tokens that omit exp, without relaxing expiry validation globally.
By @fernando-apollo in https://github.com/apollographql/router/pull/8911
Adds the ability to selectively send only specific parts of GraphQL response bodies (data, errors, or extensions) to the coprocessor, instead of the entire response body. This reduces serialization/deserialization overhead and network payload size when the coprocessor only needs to inspect certain fields.
Previously, the body configuration was a boolean that sent either the entire response body or nothing. Now it supports selective field filtering:
coprocessor:
url: http://127.0.0.1:8081
# Supergraph responses
supergraph:
response:
body:
data: false
errors: true # Only send errors
extensions: true # and extensions
# Execution responses
execution:
response:
body:
data:
The boolean syntax (body: true or body: false) continues to work for backward compatibility. When using selective filtering, the coprocessor can only modify the fields that were sent to it. Other fields are preserved from the original response.
This feature is available for the supergraph, execution, and subgraph response stages.
By @zachfettersmoore in https://github.com/apollographql/router/pull/9019
apollo.router.operations.rhai.duration histogram metric for Rhai script callbacks (PR #9072)A new apollo.router.operations.rhai.duration histogram metric (unit: s, value type: f64) is now emitted for every Rhai script callback execution across all pipeline stages. This mirrors the existing apollo.router.operations.coprocessor.duration metric.
Attributes on each datapoint:
rhai.stage — the pipeline stage (e.g. RouterRequest, SubgraphResponse)rhai.succeeded — true if the callback returned without throwing an errorBy @theJC in https://github.com/apollographql/router/pull/9072
intern_strings configuration option for the Rhai plugin (PR #9070)The Rhai plugin now exposes an intern_strings option that controls Rhai's internal string interning. Under high concurrency, threads encountering new strings must acquire a write lock, which can serialize Rhai execution across concurrent requests.
Setting intern_strings: false disables interning, eliminating the lock:
rhai:
scripts: ./rhai
main: main.rhai
intern_strings: falseString interning can alleviate memory allocation and make string equality checks a little faster. For deployments serving many concurrent requests, the cost likely outweighs the benefit, so we recommend experimenting with intern_strings: false and observing if it improves performance.
The default (true) preserves the existing behavior.
By @theJC in https://github.com/apollographql/router/pull/9070
request_duration router selector (PR #9187)Adds a new request_duration selector for the router service that returns the total elapsed time from when the router received the request. The unit is configurable:
seconds (float)milliseconds (integer)nanoseconds (integer)The selector can be used as a custom instrument attribute or combined with conditions to filter based on request duration. For example, to count requests that complete in under 10 seconds:
telemetry:
instrumentation:
instruments:
router:
my.short.requests:
type: counter
value: unit
unit: reqs
description: "Requests completing in under 10 seconds"
condition:
lt:
- request_duration: seconds
- 10By @carodewig in https://github.com/apollographql/router/pull/9187
Adds new span attributes and metrics to improve observability of streaming responses.
Span attributes:
apollo.subscription.end_reason: Records the reason a subscription was terminated. Possible values are server_close, subgraph_error, heartbeat_delivery_failed, client_disconnect, schema_reload, and config_reload.apollo.defer.end_reason: Records the reason a deferred query ended. Possible values are completed (all deferred chunks were delivered successfully) and client_disconnect (the client disconnected before all deferred data was delivered).Both attributes are added dynamically to router spans only when relevant (i.e., only on requests that actually use subscriptions or @defer), instead of being present on every router span.
Metrics:
A single counter is emitted when a subscription terminates:
apollo.router.operations.subscriptions.terminated.client (default attributes: reason, subgraph.name): Incremented once per client connection when a subscription stream ends. The reason attribute indicates why (possible values: server_close, subgraph_error, client_disconnect, heartbeat_delivery_failed, schema_reload, config_reload). The subgraph.name attribute is populated if available. When deduplication is enabled, a single subgraph WebSocket closure produces one terminated event per deduplicated client sharing that connection (each with reason=server_close).
Attributes for this metric are configurable. By default, reason and subgraph.name are enabled. You can also enable client.name via configuration:
telemetry:
instrumentation:
instruments:
router:
apollo.router.operations.subscriptions.terminated.client:
attributes:
reason: true
subgraph.name: true
client.nameThe following counter is emitted when a subscription request is rejected:
apollo.router.operations.subscriptions.rejected (attributes: reason, subgraph.name): A subscription request was rejected. The reason attribute indicates why: max_opened_subscriptions_limit_reached (the router has reached its max_opened_subscriptions limit) or subgraph (the subgraph WebSocket connection failed, e.g. connection refused, protocol error, or failed subscription handshake). The subgraph.name attribute is populated when available, and defaults to an empty string otherwise.The following counter is emitted when a subgraph ends a subscription:
apollo.router.operations.subscriptions.terminated.subgraph (attributes: subgraph.name): Incremented once per subgraph WebSocket closure. Each deduplicated client sharing that connection will also emit a corresponding apollo.router.operations.subscriptions.terminated.client event with reason=server_close.By @rohan-b99 in https://github.com/apollographql/router/pull/8858
Content-Length header in connectors (PR #9141)Connectors now correctly handle HTTP 204 (No Content) responses from spec-compliant servers that don't include a Content-Length header.
Previously, empty body detection relied on the presence of a Content-Length: 0 header. Because the HTTP spec explicitly forbids including this header in 204 responses, connectors would fail to recognize empty bodies from compliant servers. The fix checks body.is_empty() directly, with Content-Length: 0 kept as a fallback for non-compliant servers.
By @apollo-mateuswgoettems in https://github.com/apollographql/router/pull/9141
When multiple JWKS entries share identical key material (e.g., Azure AD B2C multi-policy tenants where different policies use the same RSA key), the router now correctly retries validation against all matching candidates. Previously, issuer and audience validation happened after the candidate loop, so a token that passed signature verification against the first JWKS entry would be rejected if that entry's configured issuer or audience didn't match — with no attempt to try the remaining entries.
By @carodewig in https://github.com/apollographql/router/pull/9214
The router can now handle WebSocket connections with UTF-8 encoded header values, including non-ASCII characters like "Montréal". Previously, such connections failed because of serialization issues in the underlying tungstenite library.
The fix comes from updating tokio-tungstenite from v0.28.0 to v0.29.0.
By @BobaFetters in https://github.com/apollographql/router/pull/9051
pool_idle_timeout: null in traffic_shaping configuration (PR #9165)Setting pool_idle_timeout: null in traffic_shaping configuration caused a startup failure with a schema validation error, despite null being a documented valid value that disables idle connection eviction. The JSON schema incorrectly only allowed strings. It now correctly accepts both strings and null.
By @carodewig in https://github.com/apollographql/router/pull/9165
minAvailable and maxUnavailable in the Helm PDB template (Issue #8350)Setting minAvailable: 0 or maxUnavailable: 0 in the podDisruptionBudget Helm values was silently ignored, producing a PDB with no disruption rules. This happened because Go templates treat 0 as falsy in a simple if check.
The template now uses kindIs "invalid" to correctly detect whether a value was explicitly set, and an else if to prevent both fields from being rendered simultaneously — which Kubernetes rejects. If both maxUnavailable and minAvailable are set, maxUnavailable takes precedence.
By @apollo-mateuswgoettems in https://github.com/apollographql/router/pull/9028
client.name, client.version, http.route, and http.request.method can be aliased on router spans (PR #9048)client.name and client.version have now been added to RouterAttributes, http.route has been added to HttpServerAttributes, and http.request.method has been added to HttpCommonAttributes. The default behavior should remain the same. Example configuration using aliases:
telemetry:
instrumentation:
spans:
router:
attributes:
http.route:
alias: http_route
http.request.method:
alias: http_request_methodBy @rohan-b99 in https://github.com/apollographql/router/pull/9048
When a query uses multiple fragment spreads on the same parent type and a subgraph response is missing a required non-null field on a union member, the router now correctly returns null for the affected field instead of a partial object like {"__typename": "A"}.
The GraphQL specification requires that a non-null violation propagates null upward to the nearest nullable parent. Previously, if one fragment nullified a field, a subsequent fragment on the same parent could overwrite that null with a partial result — producing a spec-incorrect response.
By @abernix in https://github.com/apollographql/router/pull/9032
Removes a wall-clock performance assertion from connector validation snapshot tests (timing is unreliable under CI load) and replaces a fixed sleep in Redis cache metrics tests with polling until command_queue_length reports zero before asserting gauges.
By @smyrick in https://github.com/apollographql/router/pull/9102
slicingArguments in demand control (PR #9196)The router supports using the length of list-type arguments as the cost multiplier in @listSize(slicingArguments: [...]), but this was not documented. Adds a new "List-type arguments in slicingArguments" subsection to the demand control docs with schema examples, query examples (both inline arrays and variables), and cost calculation breakdowns.
By @shanemyrick in https://github.com/apollographql/router/pull/9196
Documents that the router's GraphOS OTLP exporters respect the standard HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables when using the HTTP transport. Includes a note that TLS-inspecting proxies also require the proxy's root certificate to be added to the router's trust store.
Also corrects the minimum version badge for experimental_otlp_tracing_protocol / experimental_otlp_metrics_protocol to Router v1.49.0, which is when HTTP transport support was first introduced.
By @abernix in https://github.com/apollographql/router/pull/9152
apollo.router.session.count.active in favor of http.server.active_requests (PR #9069)The Standard Instruments reference now marks apollo.router.session.count.active as deprecated and directs users to http.server.active_requests instead, which follows OpenTelemetry semantic conventions. The metric remains in the router for backward compatibility but might be removed in a future release.
By @mabuyo in https://github.com/apollographql/router/pull/9069
The router can now send Apollo OTLP metrics and traces over HTTP (experimental). Enable it with these config values:
telemetry.apollo.experimental_otlp_tracing_protocoltelemetry.apollo.experimental_otlp_metrics_protocolgRPC remains the preferred transport for Apollo OTLP, but HTTP is available for deployments that can't use gRPC.
By @bonnici in https://github.com/apollographql/router/pull/9055
REQUEST_RATE_LIMITED errors when no rate limiting is configured (PR #9034)Under sustained load, the router could return REQUEST_RATE_LIMITED (429) errors even when no rate limiting was configured. An internal queue had an implicit limit that could trigger load shedding, even if the queue was not actually overloaded.
This fix removes that implicit limit, so requests are shed only when the queue is genuinely full. The queue still has explicit limits to ensure quality of service.
By @jhrldev in https://github.com/apollographql/router/pull/9034
context_id selector for telemetry to expose unique per-request identifier (PR #8899)A new context_id selector is now available for router, supergraph, subgraph, and connector telemetry instrumentation. This selector exposes the unique per-request context ID, which you can use to reliably correlate and debug requests in traces, logs, and custom events.
The context ID was previously accessible in Rhai scripts as request.id but had no telemetry selector. You can now include context_id: true in your telemetry configuration to add the context ID to spans, logs, and custom events.
Example configuration:
telemetry:
instrumentation:
spans:
router:
attributes:
"request.id":
context_id: true
supergraph:
attributes:
"request.id":
context_id: true
subgraph:
attributes:
"request.id":
context_id:
By @BobaFetters in https://github.com/apollographql/router/pull/8899
Enables Unix Domain Socket (UDS) paths for both coprocessors and subgraphs. Paths must use ?path= as the query param: unix:///tmp/some.sock?path=some_path
By @aaronarinder in https://github.com/apollographql/router/pull/8894
pool_idle_timeout for HTTP client connection pools (PR #9014)Adds a new pool_idle_timeout configuration option to the HTTP client used by subgraphs, connectors, and coprocessors. This controls how long idle keep-alive connections remain in the connection pool before being evicted. The default is 15 seconds (up from the previous hardcoded 5 seconds). Setting it to null disables the idle eviction interval entirely, meaning pooled connections are never evicted due to idleness.
The option is available at every level where HTTP client configuration applies:
traffic_shaping:
all:
pool_idle_timeout: 30s # applies to all subgraphs
subgraphs:
products:
pool_idle_timeout: 60s # per-subgraph override
connector:
all:
pool_idle_timeout: 30s # applies to all connectors
sources:
my_source:
pool_idle_timeout: 60s # per-source override
By @aaronarinder in https://github.com/apollographql/router/pull/9014
Adds a context key for the persisted query ID in the router. The PersistedQueryLayer now stores the persisted query ID in the request context, and the Rhai engine can access it via that key.
By @faisalwaseem in https://github.com/apollographql/router/pull/8959
Adds a RetryMetricExporter layer that retries up to three times with jittered exponential backoff for the apollo metrics and otlp named exporters.
By @rohan-b99 in https://github.com/apollographql/router/pull/9036
PR #8767 (released in Router v2.11.0) changed the entity and response caching keys to support nullable elements. The implementation covered the case of a field explicitly being set to null, but didn't cover the following cases:
This change adds support for those cases.
By @carodewig in https://github.com/apollographql/router/pull/8923
h2 dependency at minimum v0.4.13 to pick up critical flow-control, deadlock, and tracing fixes (PR #9033)h2 0.4.13 (released January 5, 2026) contains three fixes directly relevant to the router, which uses h2 exclusively as a client when connecting to subgraphs:
Capacity deadlock under concurrent streams (#860) — high relevance: Under concurrent load with max_concurrent_streams limits in effect, flow-control capacity could be assigned to streams still in pending_open state. Those streams could never consume the capacity, starving already-open streams and permanently freezing all outgoing traffic on the connection with no error surfaced. This is directly triggerable in the router: any subgraph behind Envoy or a gRPC backend advertises a max_concurrent_streams limit (Envoy defaults to 100), and under production load the router will routinely queue more concurrent requests than that limit allows.
OTel tracing span lifetime leak (#868) — high relevance: The h2 Connection object captured the active tracing span at connection creation time as its parent, keeping that span alive for the entire lifetime of the connection. Since the router wraps every subgraph request in an OpenTelemetry span and connections are pooled, affected spans could linger indefinitely under sustained traffic — never being exported to the tracing backend and accumulating in memory.
Flow-control stall on padded DATA frames (#869) — lower relevance for typical subgraphs, higher for connectors: Padding bytes in DATA frames were not being returned to the flow-control window, causing the connection window to drain to zero and permanently stalling downloads with no error. Typical GraphQL/gRPC subgraphs do not send padded frames, but router connectors calling arbitrary HTTP APIs (e.g., Google Cloud Storage or CDN-backed endpoints) can encounter this.
By @theJC in https://github.com/apollographql/router/pull/9033
Reverts PR #8765.
When the router's rate limit or buffer capacity is exceeded, it now returns HTTP 503 (Service Unavailable) instead of HTTP 429 (Too Many Requests).
HTTP 429 implies that a specific client has sent too many requests and should back off. HTTP 503 more accurately reflects the situation: the router is temporarily unable to handle the request due to overall service load, not because of the behavior of any individual client.
This change affects both router-level and subgraph-level rate limiting. Documentation has been updated to reflect the new status code.
By @carodewig in https://github.com/apollographql/router/pull/9013
Cache-Control: no-store when the response cache returns GraphQL errors (PR #8933)When using the response cache plugin, if a query spans multiple subgraphs and one returns an error or times out, the final HTTP response was still carrying the successful subgraph's Cache-Control header (e.g. max-age=1800, public). This allowed intermediate caches (CDNs, reverse proxies) to cache and serve incomplete or stale partial responses to other clients.
If the response cache plugin is enabled and was going to set a Cache-Control header, but the response contains any GraphQL errors, it now sets Cache-Control: no-store instead of the merged subgraph cache control value.
By @carodewig in https://github.com/apollographql/router/pull/8933
When making an entity resolution, if entity resolution fails (for example, because the path from the subgraph was malformed), the router applied errors to every item in the list of entities expected. For example, if 2000 entities were expected but 2000 errors were returned instead, each error was applied to every entity. This causes an explosion of errors and leads to significant memory allocations that can cause OOMKills.
When the router can't determine where an error should be applied, it now applies it to the most immediate parent of the targeted entity — for a list of users, it applies to the list itself rather than to each index of that list.
By @aaronArinder in https://github.com/apollographql/router/pull/8962
http.client.response.body.size and http.server.response.body.size consistently when content-length is absent or compression is used (PR #8972)Reporting these metrics previously relied on either the Content-Length header or the size_hint of the body, which reports the uncompressed size. OpenTelemetry semantic conventions recommend reporting the compressed size.
The router now consistently reports the compressed size when compression is used, even when Content-Length is absent, for:
By @rohan-b99 in https://github.com/apollographql/router/pull/8972
The metric apollo.router.query_planner.memory was unintentionally only showing allocations during the query_parsing compute job if cooperative cancellation for query planning was not enabled. Both query_parsing and query_planning should now be available.
By @rohan-b99 in https://github.com/apollographql/router/pull/8902
ServiceMonitor naming with other chart resources using the router.fullname helper (Issue #TSH-22160)The ServiceMonitor Helm resource was using .Release.Name directly as its metadata.name, while all other chart resources (e.g. Service, Deployment) already used the router.fullname helper. This caused a naming inconsistency: for a release named my-release, the Service would be named my-release-router but the ServiceMonitor would be named my-release.
This change aligns the ServiceMonitor name with the rest of the chart by using {{ include "router.fullname" . }}, ensuring consistent naming and proper support for nameOverride and fullnameOverride values.
By @mateusgoettems in https://github.com/apollographql/router/pull/8929
When the query planner rejected a request because all fields were unauthorized, the response always placed errors in the errors array and returned data: {}, ignoring the configured errors.response location (errors, extensions, or disabled). The router now returns data: null and respects errors.response and errors.log, consistent with partially-unauthorized requests.
By @carodewig in https://github.com/apollographql/router/pull/9022
deprecated enum values when merging coprocessor context (PR #8913)A change to coprocessor context merges in Router v2.10 caused keys to be deleted when context: true is used as the coprocessor context selector in the router configuration file.
The workaround was to pass context: deprecated instead. This change brings parity when context: true is provided.
By @carodewig in https://github.com/apollographql/router/pull/8913
The router now fails to start if any of the following OpenTelemetry (OTEL) environment variables are set:
OTEL_EXPORTER_OTLP_ENDPOINTOTEL_EXPORTER_OTLP_TRACES_ENDPOINTOTEL_EXPORTER_OTLP_METRICS_ENDPOINTUsing these variables isn't supported by the router because they can override or interfere with its built-in telemetry configuration, leading to unexpected behavior.
Previously, the router emitted a warning when OTEL_EXPORTER_OTLP_ENDPOINT was present. Startup is now blocked to prevent unintended telemetry configuration conflicts.
If your deployment defines any of these environment variables (for example, through base container images, platform defaults, or infrastructure tooling), remove them before starting the router.
By @OriginLeon in https://github.com/apollographql/router/pull/8915
The readiness ticker recreated its interval_at inside the recovery loop on every cycle, which reset the sampling window clock each time the router returned to ready. This caused inconsistent sampling behavior across recovery cycles. Additionally, the rejection counter was read and zeroed with separate atomic operations (load + store(0)), leaving a race window where rejections arriving between the two operations could be silently dropped.
The fix creates the interval once outside the loop, sets MissedTickBehavior::Delay to prevent catch-up ticks after the recovery sleep, and uses swap(0, Relaxed) to atomically read and reset the rejection counter in a single operation.
By @OriginLeon in https://github.com/apollographql/router/pull/8966
http2only uses h2c for cleartext connections (PR #9018)hyper does not support upgrading cleartext connections from HTTP/1.1 to HTTP/2. To use HTTP/2 without TLS, clients must use 'prior knowledge' — connecting with the HTTP/2 preface directly. This is what experimental_http2: http2only is for, but previously HTTP/1 was always enabled in the connector, causing the client to fall back to HTTP/1.1 regardless. This fix applies to all outbound HTTP connections: subgraphs, connectors, and coprocessors.
experimental_http2 | TLS | protocol used |
|---|---|---|
disable | yes | HTTP/1.1 |
disable | no | HTTP/1.1 |
enable | yes | HTTP/2 (if server supports it), else HTTP/1.1 |
enable | no | HTTP/1.1 |
http2only | yes | HTTP/2 |
http2only | no | HTTP/2 (h2c — cleartext prior knowledge) |
By @carodewig in https://github.com/apollographql/router/pull/9018
Rejects invalid values (validated against a regex) for library name and version provided in headers or operation extensions, which are used for the Client Awareness feature and telemetry.
By @BoD in https://github.com/apollographql/router/pull/8934
no-store and no-cache behavior for response cache and entity cache plugins (PR #8948 and PR #8952)no-store and no-cache have different meanings. Per RFC 9111:
no-store: allows serving a response from cache, but prohibits storing the response in cacheno-cache: prohibits serving a response from cache, but allows storing the response in cache(Note: no-cache actually prohibits serving a response from cache without revalidation — but the router doesn't distinguish between lookup and revalidation.)
The response caching and entity caching plugins were incorrectly treating no-store as both 'no serving response from the cache' and 'no storing response in the cache.' This change corrects that behavior.
By @carodewig in https://github.com/apollographql/router/pull/8948 and https://github.com/apollographql/router/pull/8952
exists conditions with request_header selectors on response-stage coprocessor and event configurations (PR #8964)Using exists: { request_header: <name> } as a condition on response-stage coprocessor or telemetry event configurations (e.g. on: response) previously caused the router to reject the configuration at startup with a validation error, even though the condition is valid and works correctly at runtime.
The validator was incorrectly rejecting request-stage selectors inside Exists conditions for response-stage configurations. This is safe because evaluate_request() pre-resolves these conditions before they are stored for response-time evaluation: if the header is present the condition becomes True; if absent, the event or coprocessor call is discarded and never reaches the response stage.
By @OriginLeon in https://github.com/apollographql/router/pull/8964
You can configure a list of safe registry hostnames to enable the router to pull graph artifacts over HTTP instead of HTTPS. Insecure registries are commonly run within a private network such as a Kubernetes cluster or as a pull-through cache, where you want to avoid the overhead of setting up and distributing SSL certificates.
By @sirddoger in https://github.com/apollographql/router/pull/8919
The router now uses v0.31.0 of the OpenTelemetry Rust libraries. This update includes many bug fixes and performance improvements from upstream.
The router doesn't guarantee the stability of downstream pre-1.0 APIs, so users that directly interact with OpenTelemetry must update their code accordingly.
As part of this upgrade, Zipkin Native exporter is deprecated upstream. Switch to the OTLP exporter, which Zipkin now supports natively. Note that Zipkin Native exporter no longer supports setting a service name — if you need this, switch to the OTLP exporter.
By @BrynCooke @goto-bus-stop @rohan-b99 in https://github.com/apollographql/router/pull/8922
cargo build --locked --release in DIY Dockerfile.repo for deterministic, lockfile-respecting builds (PR #8983)The DIY Dockerfile.repo previously used cargo install --path apollo-router, which doesn't enforce the versions in Cargo.lock — resulting in possible non-deterministic dependency resolution and builds that could diverge from what CI produces.
Using cargo build --locked --release -p apollo-router ensures the versions in the lockfile are respected and the DIY build path more closely aligns with CI.
By @theJC in https://github.com/apollographql/router/pull/8983
Updates the API gateway subscriptions documentation to reflect that Amazon API Gateway now supports response streaming for REST APIs. HTTP multipart subscriptions are supported when the router is behind AWS API Gateway. Includes a link to the AWS announcement (November 2025) and a short configuration note linking to Response transfer mode.
By @smyrick in https://github.com/apollographql/router/pull/8907
experimental_hoist_orphan_errors configurationAdds the experimental_hoist_orphan_errors configuration option to the YAML configuration reference. The documentation covers the feature's purpose (reducing multiplicative error propagation from entity resolution), per-subgraph and global enablement examples, the spec compliance caveat, and the known limitation that error counts are reduced but not hard-capped.
By @andywgarcia in https://github.com/apollographql/router/pull/8999