Releases: apollographql/router
v1.46.0
馃殌 Features
Entity cache preview: support queries with private scope (PR #4855)
This feature is part of the work on subgraph entity caching, currently in preview.
The router now supports caching responses marked with private
scope. This caching currently works only on subgraph responses without any schema-level information.
For details about the caching behavior, see PR #4855
Add support of custom events defined by YAML for telemetry (Issue #4320)
Users can now configure telemetry events via YAML
to log that something has happened (e.g. a request had errors of a particular type) without reaching for Rhai or a custom plugin.
Events may be triggered on conditions and can include information in the request/response pipeline as attributes.
Here is an example of configuration:
telemetry:
instrumentation:
events:
router:
# Standard events
request: info
response: info
error: info
# Custom events
my.event:
message: "my event message"
level: info
on: request
attributes:
http.response.body.size: false
# Only log when the x-log-request header is `log`
condition:
eq:
- "log"
- request_header: "x-log-request"
supergraph:
# Custom event configuration for supergraph service ...
subgraph:
# Custom event configuration for subgraph service .
Ability to ignore auth prefixes in the JWT plugin
The router now supports a configuration to ignore header prefixes with the JWT plugin. Given that many application headers use the format of Authorization: <scheme> <token>
, this option enables the router to process requests for specific schemes within the Authorization
header while ignoring others.
For example, you can configure the router to process requests with Authorization: Bearer <token>
defined while ignoring others such as Authorization: Basic <token>
:
authentication:
router:
jwt:
header_name: authorization
header_value_prefix: "Bearer"
ignore_mismatched_prefix: true
If the header prefix is an empty string, this option is ignored.
Support conditions on custom attributes for spans and a new selector for GraphQL errors (Issue #4336)
The router now supports conditionally adding attributes on a span and the new on_graphql_error
selector that is set to true if the response body contains GraphQL errors.
An example configuration using condition
in attributes
and on_graphql_error
:
telemetry:
instrumentation:
spans:
router:
attributes:
otel.status_description:
static: "there was an error"
condition:
any:
- not:
eq:
- response_status: code
- 200
- eq:
- on_graphql_error
- true
馃悰 Fixes
Federation v2.7.5 (PR #5064)
This brings in a query planner fix released in v2.7.5 of Apollo Federation. Notably, from its changelog:
-
Fix issue with missing fragment definitions due to
generateQueryFragments
. (#2993)An incorrect implementation detail in
generateQueryFragments
caused certain queries to be missing fragment definitions, causing the operation to be invalid and fail early in the request life-cycle (before execution). Specifically, subsequent fragment "candidates" with the same type condition and the same length of selections as a previous fragment weren't correctly added to the list of fragments. An example of an affected query is:query { t { ... on A { x y } } t2 { ... on A { y z } } }
In this case, the second selection set would be converted to an inline fragment spread to subgraph fetches, but the fragment definition would be missing
By @garypen in #5064
Use supergraph schema to extract authorization info (PR #5047)
The router now uses the supergraph schema to extract authorization info, as authorization information may not be available on the query planner's subgraph schemas. This reverts the authorization changes made in PR #4975.
By @tninesling in #5047
Filter fetches added to batch during batch creation (PR #5034)
Previously, the router didn't filter query hashes when creating batches. This could result in failed queries because the additional hashes could incorrectly make a query appear to be committed when it wasn't actually registered in a batch.
This release fixes this issue by filtering query hashes during batch creation.
Use subgraph.name
attribute instead of apollo.subgraph.name
(PR #5012)
In the router v1.45.0, subgraph name mapping didn't work correctly in the Datadog exporter.
The Datadog exporter does some explicit mapping of attributes and was using a value apollo.subgraph.name
that the latest versions of the router don't use. The correct choice is subgraph.name
.
This release updates the mapping to reflect the change and fixes subgraph name mapping for Datadog.
馃摎 Documentation
Document traffic shaping default configuration (PR #4953)
The documentation for configuring traffic shaping has been updated to clarify that it's enabled by default with preset values. This setting has been the default since PR #3330, which landed in v1.23.0.
馃И Experimental
Experimental type conditioned fetching (PR #4748)
This release introduces an experimental configuration to enable type-conditioned fetching.
Previously, when querying a field that was in a path of two or more unions, the query planner wasn't able to handle different selections and would aggressively collapse selections in fetches. This resulted in incorrect plans.
Enabling the experimental_type_conditioned_fetching
option can fix this issue by configuring the query planner to fetch with type conditions.
experimental_type_conditioned_fetching: true # false by default
By @o0Ignition0o in #4748
v1.46.0-rc.3
1.46.0-rc.3
v1.46.0-rc.1
1.46.0-rc.1
v1.46.0-rc.0
1.46.0-rc.0
v1.45.1
馃悰 Fixes
Correct v1.44.0 regression in query plan cache (PR #5028)
Correct a critical regression that was introduced in v1.44.0 which could lead to execution of an incorrect query plan. This issue only affects Routers that use distributed query plan caching, enabled via the supergraph.query_planning.cache.redis.urls
configuration property.
By @o0Ignition0o in #5028
Use entire schema when hashing an introspection query (Issue #5006)
Correct a different hashing bug which impacted introspection queries which was also introduced in v1.44.0. This other hashing bug failed to account for introspection queries, resulting in introspection results being misaligned to the current schema. This issue only affects Routers that use distributed query plan caching, enabled via the supergraph.query_planning.cache.redis.urls
configuration property.
This release fixes the hashing mechanism by adding the schema string to hashed data if an introspection field is encountered. As a result, the entire schema is taken into account and the correct introspection result is returned.
Fix subgraph name mapping of Datadog exporter (PR #5012)
Previously in the router v1.45.0, subgraph name mapping didn't work correctly in the router's Datadog exporter. The exporter used the incorrect value apollo.subgraph.name
for mapping attributes when it should have used the value subgraph.name
. This issue has been fixed in this release.
v1.45.1-rc.1
1.45.1-rc.1
v1.45.1-rc.0
1.45.1-rc.0
v1.45.0
Caution
This version has a critical bug impacting users of distributed query plan caching. See the Fixes in v1.45.1 for details. We highly recommend using v1.45.1 (or newer) or v1.43.2 over v1.45.0.
馃殌 Features
Query validation process with Rust (PR #4551)
The router has been updated with a new Rust-based query validation process using apollo-compiler
from the apollo-rs
project. It replaces the Javascript implementation in the query planner. It improves query planner performance by moving the validation out of the query planner and into the router service, which frees up space in the query planner cache.
Because validation now happens earlier in the router service and not in the query planner, error paths in the query planner are no longer encountered. Some messages in error responses returned from invalid queries should now be more clear.
We've tested the new validation process by running it for months in production, concurrently with the JavaScript implementation, and have now completely transitioned to the Rust-based implementation.
Add support for SHA256 hashing in Rhai (Issue #4939)
The router supports a new sha256
module to create SHA256 hashes in Rhai scripts. The module supports the sha256::digest
function.
An example script that uses the module:
fn supergraph_service(service){
service.map_request(|request|{
log_info("hello world");
let sha = sha256::digest("hello world");
log_info(sha);
});
}
Subgraph support for query batching (Issue #2002)
As an extension to the ongoing work to support client-side query batching in the router, the router now supports batching of subgraph requests. Each subgraph batch request retains the same external format as a client batch request. This optimization reduces the number of round-trip requests from the router to subgraphs.
Also, batching in the router is now a generally available feature: the experimental_batching
router configuration option has been deprecated and is replaced by the batching
option.
Previously, the router preserved the concept of a batch until a RouterRequest
finished processing. From that point, the router converted each batch request item into a separate SupergraphRequest
, and the router planned and executed those requests concurrently within the router, then reassembled them into a batch of RouterResponse
to return to the client. Now with the implementation in this release, the concept of a batch is extended so that batches are issued to configured subgraphs (all or named). Each batch request item is planned and executed separately, but the queries issued to subgraphs are optimally assembled into batches which observe the query constraints of the various batch items.
To configure subgraph batching, you can enable batching.subgraph.all
for all subgraphs. You can also enable batching per subgraph with batching.subgraph.subgraphs.*
. For example:
batching:
enabled: true
mode: batch_http_link
subgraph:
# Enable batching on all subgraphs
all:
enabled: true
batching:
enabled: true
mode: batch_http_link
subgraph:
# Disable batching on all subgraphs
all:
enabled: false
# Configure (override) batching support per subgraph
subgraphs:
subgraph_1:
enabled: true
subgraph_2:
enabled: true
Note: all
can be overridden by subgraphs
. This applies in general for all router subgraph configuration options.
To learn more, see query batching in Apollo docs.
馃悰 Fixes
Update rustls
to v0.21.11, the latest v0.21.x patch (PR #4993)
While the Router does use rustls
, RUSTSEC-2024-0336 (also known as CVE-2024-32650 and GHSA-6g7w-8wpp-frhj) DOES NOT affect the Router since it uses tokio-rustls
which is specifically called out in the advisory as unaffected.
Despite the lack of impact, we update rustls
version v0.21.10 to rustls v0.21.11 which includes a patch.
By @tninesling in #4993
Performance improvements for Apollo usage report field generation (PR 4951)
The performance of generating Apollo usage report signatures, stats keys, and referenced fields has been improved.
Apply alias rewrites to arrays (PR #4958)
The automatic aliasing rules introduced in #2489 to support @interfaceObject
are now properly applied to lists.
By @o0Ignition0o in #4958
Fix compatibility of coprocessor metric creation (PR #4930)
Previously, the router's execution stage created coprocessor metrics differently than other stages. This produced metrics with slight incompatibilities.
This release fixes the issue by creating coprocessor metrics in the same way as all other stages.
馃摎 Documentation
Documentation updates for caching and metrics instruments (PR #4872)
Router documentation has been updated for a couple topics:
- Performance improvements vs. stability concerns when using the router's operation cache
- Overview of standard and custom metrics instruments
馃И Experimental
Experimental: Introduce a pool of query planners (PR #4897)
The router supports a new experimental feature: a pool of query planners to parallelize query planning.
You can configure query planner pools with the supergraph.query_planning.experimental_parallelism
option:
supergraph:
query_planning:
experimental_parallelism: auto # number of available CPUs
Its value is the number of query planners that run in parallel, and its default value is 1
. You can set it to the special value auto
to automatically set it equal to the number of available CPUs.
You can discuss and comment about query planner pools in this GitHub discussion.
By @xuorig and @o0Ignition0o in #4897
Experimental: Rust implementation of Apollo usage report field generation (PR 4796)
The router supports a new experimental Rust implementation for generating the stats report keys and referenced fields that are sent in Apollo usage reports. This implementation is one part of the effort to replace the router-bridge with native Rust code.
The feature is configured with the experimental_apollo_metrics_generation_mode
setting. We recommend that you use its default value, so we can verify that it generates the same payloads as the previous implementation.
v1.45.0-rc.1
1.45.0-rc.1
v1.45.0-rc.0
1.45.0-rc.0