[!IMPORTANT] Due to a CI bug, our ARM64 Docker images published for v2.6.0 incorrectly contained AMD64/x86 artifacts. This is fixed in v2.6.1.
This change adds a new, experimental histogram to capture subgraph fetch duration for GraphOS. This will eventually be used to power subgraph-level insights in Apollo Studio.
This can be toggled on using a new boolean config flag:
telemetry:
apollo:
experimental_subgraph_metrics: true
The new instrument is only sent to GraphOS and is not available in 3rd-party OTel export targets. It is not currently
customizable. Users requiring a customizable alternative can use the existing http.client.request.duration
instrument, which measures the same value.
By @rregitsky in https://github.com/apollographql/router/pull/8013 and https://github.com/apollographql/router/pull/8045
The router now provides Redis cache monitoring with new metrics that help track performance, errors, and resource usage.
Connection and performance metrics:
apollo.router.cache.redis.connections: Number of active Redis connectionsapollo.router.cache.redis.command_queue_length: Commands waiting to be sent to Redis, indicates if Redis is keeping up with demandapollo.router.cache.redis.commands_executed: Total number of Redis commands executedapollo.router.cache.redis.redelivery_count: Commands retried due to connection issuesapollo.router.cache.redis.errors: Redis errors by type, to help diagnose authentication, network, and configuration problemsExperimental performance metrics:
experimental.apollo.router.cache.redis.network_latency_avg: Average network latency to Redisexperimental.apollo.router.cache.redis.latency_avg: Average Redis command execution timeexperimental.apollo.router.cache.redis.request_size_avg: Average request payload sizeexperimental.apollo.router.cache.redis.response_size_avg: Average response payload size[!NOTE] The experimental metrics may change in future versions as we improve the underlying Redis client integration.
You can configure how often metrics are collected using the metrics_interval setting:
supergraph:
query_planning:
cache:
redis:
urls: ["redis://localhost:6379"]
ttl: "60s"
metrics_interval: "1s" # Collect metrics every second (default: 1s)
By @BrynCooke in https://github.com/apollographql/router/pull/7920
The router license functionality now allows granular specification of features enabled to support current and future pricing plans.
By @DMallare in https://github.com/apollographql/router/pull/7917
This adds new custom instrument selectors for Connectors and enhances some existing selectors. The new selectors are:
supergraph_operation_name
supergraph_operation_kind
query, mutation, subscription)request_context
connector_on_response_error
is_successful condition. Or, if that condition is not set,
returns true when the response has a non-200 status codeThese selectors were modified to add additional functionality:
connector_request_mapping_problems
boolean variant that will return true when a mapping problem exists on the requestconnector_response_mapping_problems
boolean variant that will return true when a mapping problem exists on the responseBy @rregitsky in https://github.com/apollographql/router/pull/8045
This PR enables the jemalloc allocator on MacOS by default, making it easier to do memory profiling. Previously, this was only done for Linux.
By @Velfi in https://github.com/apollographql/router/pull/8046
When the Subgraph Entity Caching feature is in use, it determines the Cache-Control HTTP response header sent to supergraph clients based on those received from subgraph servers.
In this process, Apollo Router only emits the max-age directive and not s-maxage.
This PR fixes a bug where, for a query that involved a single subgraph fetch that was not already cached, the subgraph response’s Cache-Control header would be forwarded as-is.
Instead, it now goes through the same algorithm as other cases.
By @SimonSapin in https://github.com/apollographql/router/pull/7987
The router now correctly generates query plans when using progressive override (@override with labels) on types that implement interfaces within the same subgraph. Previously, the Rust query planner would fail to generate plans for these scenarios with the error "Was not able to find any options for {}: This shouldn't have happened.", while the JavaScript planner handled them correctly.
This fix resolves planning failures when your schema uses:
The router will now successfully plan and execute queries that previously resulted in query planning errors.
By @TylerBloom in https://github.com/apollographql/router/pull/7929
The Multipart HTTP protocol for GraphQL Subscriptions distinguishes between GraphQL-level errors and fatal transport-level errors. The router previously used a heuristic to determine if a given error was fatal or not, which could sometimes cause errors to be wrongly classified. For example, if a subgraph returned a GraphQL-level error for a subscription and then immediately ended the subscription, the router might propagate this as a fatal transport-level error.
This is now fixed. Fatal transport-level errors are tagged as such when they are constructed, so the router can reliably know how to serialize errors when sending them to the client.
By @goto-bus-stop in https://github.com/apollographql/router/pull/7901
Now that we have a DockerHub account we have published the Runtime Container to that account. This fix simply adds a reference to that to the documentation
By @jonathanrainer in https://github.com/apollographql/router/pull/8054
Fetched April 11, 2026