🚀 Features
Promote HTTP request size limit from experimental to general availability (PR #4442)
In this release, the router YAML configuration option to set the maximum size of an HTTP request body is promoted from experimental to general availability. The option was previously experimental_http_max_request_bytes and is now http_max_request_bytes.
The previous experimental_http_max_request_bytes option works but produces a warning.
To migrate, rename experimental_http_max_request_bytes to the generally available http_max_request_bytes option:
limits:
http_max_request_bytes: 2000000 # Default value: 2 MBBy default, the Apollo Router limits the size of the HTTP request body it reads from the network to 2 MB. Before increasing this limit, consider testing performance in an environment similar to your production, especially if some clients are untrusted. Many concurrent large requests can cause the router to run out of memory.
By @SimonSapin in #4442
New configuration options for Redis username and password (Issue #4346)
This release introduces new configuration options to set your Redis username and password.
Example of configuration:
supergraph:
query_planning:
experimental_cache:
redis: #highlight-line
urls: ["redis://..."] #highlight-line
username: admin/123 # Optional, can be part of the urls directly, mainly useful if you have special character like '/' in your password that doesn't work in url. This field takes precedence over the username in the URL
password: admin # Optional, can be part of the urls directly, mainly useful if you have special character like '/' in your password that doesn't work in url. This field takes precedence over the password in the URL
timeout: 5ms # Optional, by default: 2ms
ttl: 24h # Optional, by default no expirationSupport Redis key namespace (Issue #4247)
This release introduces support for Redis key namespace.
The namespace, if provided, is prefixed to the key: namespace:key.
🐛 Fixes
Fix the Datadog default tracing exporter URL (Issue #4415)
The default URL for the Datadog exporter was incorrectly set to http://localhost:8126/v0.4/traces. This caused issues for users running different agent versions.
This is now fixed and matches the exporter URL of http://127.0.0.1:8126.
By @BrynCooke in #4444
Set application default log level to info (PR #4451)
This release sets the default log level to info for an entire application, including custom external plugins, when the RUST_LOG environment variable isn't set.
Previously, if you set the --log command-line option or APOLLO_RUST_LOG environment variable, their log level setting impacted more than the apollo_router crate and caused custom plugins with info logs or metrics to have to manually set RUST_LOG=info.
Note: setting
RUST_LOGchanges the application log level.
Fix response format for statically skipped root selection set (Issue #4397)
Previously, the Apollo Router didn't return responses with the same format for some operations with a root selection set that were skipped by @skip or @include directives.
For example, if you hardcoded the parameter in a @skip directive:
{
get @skip(if: true) {
id
name
}
}Or if you used a variable:
{
get(: Boolean = true) @skip(if: ) {
id
name
}
}The router returned responses with different formats.
This release fixes the issue, and the router returns the same response for both examples:
{ "data": {}}Fix building entity representations with inline fragments (PR #4441)
Previously, when applying a selection set to an entity reference before it's used in a fetch node, the router would drop data from the reference when it selected using an inline fragment, for example @requires(fields: "... on Foo { a } ... on Bar { b }")).
This release uses a more flexible abstract type / concrete type check when applying a selection set to an entity reference before it's used in a fetch node.
By @lennyburdette in #4441
Improve logging for JWKS download failures (Issue #4448)
To enable users to debug JWKS download and parse failures more easily, we've added more detailed logging to the router. The router now logs the following information when a JWKS download or parse fails:
2024-01-09T12:32:20.174144Z ERROR fetch jwks{url=http://bad.jwks.com/,} could not create JSON Value from url content, enable debug logs to see content e=expected value at line 1 column 1
Enabling debug logs via APOLLO_LOG=debug or --logs DEBUG will show the full JWKS content being parsed:
2024-01-09T12:32:20.153055Z DEBUG fetch jwks{url=http://bad.jwks.com/,} parsing JWKS data="invalid jwks"
By @BrynCooke in #4449
Rename batching metric for naming convention conformance (PR #4424)
In this release, the apollo_router.operations.batching metric has been renamed to apollo.router.operations.batching to conform to our naming convention of a apollo.router. prefix.
Improve JWKS parse error handling (Issue #4463)
When parsing a JSON Web Key Set (JWKS), the router now ignores any JWK that fails to parse rather than failing the entire JWKS parse.
This can happen when the JWK is malformed, or when a JWK uses an unknown algorithm. When this happens a warning is output to the logs, for example:
2024-01-11T15:32:01.220034Z WARN fetch jwks{url=file:///tmp/jwks.json,} ignoring a key since it is not valid, enable debug logs to full content err=unknown variant `UnknownAlg`, expected one of `HS256`, `HS384`, `HS512`, `ES256`, `ES384`, `RS256`, `RS384`, `RS512`, `PS256`, `PS384`, `PS512`, `EdDSA` alg="UnknownAlg" index=2
Log messages have the following attributes:
alg- the JWK algorithm if known or<unknown>index- the index of the JWK within the JWKSurl- the URL of the JWKS that had the issue
By @BrynCooke in #4465
make OperationKind public (Issue #4410)
OperationKind was already used in a public field but the type itself was still private.
Update to Federation v2.6.3 (PR #4468)
This federation update contains query planning fixes for:
- Invalid typename used when calling into a subgraph that uses
@interfaceObject - A performance issue when generating planning paths for union members that use
@requires
🛠 Maintenance
Pre-built binaries are only available for Apple Silicon (Issue #3902)
Prior to this release, macOS binaries were produced on Intel build machines in our CI pipeline. The binaries produced would also work on Apple Silicon (M1, etc.. chips) through the functionality provided by Rosetta2.
Our CI provider has announced the deprecation of the macOS Intel build machines and we are updating our build pipeline to use the new Apple Silicon based machines.
This will have the following effects:
- Older, Intel based, macOS systems will no longer be able to execute our macOS router binaries.
- Newer, Apple Silicon based, macOS systems will get a performance boost due to no longer requiring Rosetta2 support.
We have raised an issue that describes options for Intel based macOS users. Please let us know in that issue if the alternatives we suggest (e.g., Docker, source build) don't work for you so we can discuss alternatives.