chore(deps): update ghcr.io/apollographql/router docker tag to v1.59.1 - autoclosed

[renovate]

This PR contains the following updates:

Package	Update	Change
ghcr.io/apollographql/router	minor	v1.56.0 -> v1.59.1

---

Release Notes

apollographql/router (ghcr.io/apollographql/router)

v1.59.1

Compare Source

🐛 Fixes

Fix transmitted header value for Datadog priority sampling resolution (PR #​6017)

The router now transmits correct values of x-datadog-sampling-priority to downstream services.

Previously, an x-datadog-sampling-priority of -1 was incorrectly converted to 0 for downstream requests, and 2 was incorrectly converted to 1. When propagating to downstream services, this resulted in values of USER_REJECT being incorrectly transmitted as AUTO_REJECT.

Enable accurate Datadog APM metrics (PR #​6017)

The router supports a new preview feature, the preview_datadog_agent_sampling option, to enable sending all spans to the Datadog Agent so APM metrics and views are accurate.

Previously, the sampler option in telemetry.exporters.tracing.common.sampler wasn't Datadog-aware. To get accurate Datadog APM metrics, all spans must be sent to the Datadog Agent with a psr or sampling.priority attribute set appropriately to record the sampling decision.

The preview_datadog_agent_sampling option enables accurate Datadog APM metrics. It should be used when exporting to the Datadog Agent, via OTLP or Datadog-native.

telemetry:
  exporters:
    tracing:
      common:

### Only 10 percent of spans will be forwarded from the Datadog agent to Datadog. Experiment to find a value that is good for you!
        sampler: 0.1

### Send all spans to the Datadog agent.
        preview_datadog_agent_sampling: true

Using these options can decrease your Datadog bill, because you will be sending only a percentage of spans from the Datadog Agent to Datadog.

[!IMPORTANT]

• Users must enable preview_datadog_agent_sampling to get accurate APM metrics. Users that have been using recent versions of the router will have to modify their configuration to retain full APM metrics.
• The router doesn't support in-agent ingestion control.
• Configuring traces_per_second in the Datadog Agent won't dynamically adjust the router's sampling rate to meet the target rate.
• Sending all spans to the Datadog Agent may require that you tweak the batch_processor settings in your exporter config. This applies to both OTLP and Datadog native exporters.

Learn more by reading the updated Datadog tracing documentation for more information on configuration options and their implications.

Fix non-parent sampling (PR #​6481)

When the user specifies a non-parent sampler the router should ignore the information from upstream and use its own sampling rate.

The following configuration would not work correctly:

  exporters:
    tracing:
      common:
        service_name: router
        sampler: 0.00001
        parent_based_sampler: false

All spans are being sampled.
This is now fixed and the router will correctly ignore any upstream sampling decision.

By @​BrynCooke in https://github.com/apollographql/router/pull/6481

v1.59.0

Compare Source

[!IMPORTANT]
If you have enabled distributed query plan caching, updates to the query planner in this release will result in query plan caches being regenerated rather than reused. On account of this, you should anticipate additional cache regeneration cost when updating to this router version while the new query plans come into service.

🚀 Features

General availability of native query planner

The router's native, Rust-based, query planner is now generally available and enabled by default.

The native query planner achieves better performance for a variety of graphs. In our tests, we observe:

• 10x median improvement in query planning time (observed via apollo.router.query_planning.plan.duration)
• 2.9x improvement in router’s CPU utilization
• 2.2x improvement in router’s memory usage

Note: you can expect generated plans and subgraph operations in the native
query planner to have slight differences when compared to the legacy, JavaScript-based query planner. We've ascertained these differences to be semantically insignificant, based on comparing ~2.5 million known unique user operations in GraphOS as well as
comparing ~630 million operations across actual router deployments in shadow
mode for a four month duration.

The native query planner supports Federation v2 supergraphs. If you are using Federation v1 today, see our migration guide on how to update your composition build step. Subgraph changes are typically not needed.

The legacy, JavaScript, query planner is deprecated in this release, but you can still switch
back to it if you are still using Federation v1 supergraph:

experimental_query_planner_mode: legacy

Note: The subgraph operations generated by the query planner are not
guaranteed consistent release over release. We strongly recommend against
relying on the shape of planned subgraph operations, as new router features and
optimizations will continuously affect it.

By @​sachindshinde, @​goto-bus-stop, @​duckki, @​TylerBloom, @​SimonSapin, @​dariuszkuc, @​lrlna, @​clenfest, and @​o0Ignition0o.

Ability to skip persisted query list safelisting enforcement via plugin (PR #​6403)

If safelisting is enabled, a router_service plugin can skip enforcement of the safelist (including the require_id check) by adding the key apollo_persisted_queries::safelist::skip_enforcement with value true to the request context.

Note: this doesn't affect the logging of unknown operations by the persisted_queries.log_unknown option.

In cases where an operation would have been denied but is allowed due to the context key existing, the attribute persisted_queries.safelist.enforcement_skipped is set on the apollo.router.operations.persisted_queries metric with value true.

By @​glasser in https://github.com/apollographql/router/pull/6403

Add fleet awareness plugin (PR #​6151)

A new fleet_awareness plugin has been added that reports telemetry to Apollo about the configuration and deployment of the router.

The reported telemetry include CPU and memory usage, CPU frequency, and other deployment characteristics such as operating system and cloud provider. For more details, along with a full list of data captured and how to opt out, go to our
data privacy policy.

By @​jonathanrainer, @​nmoutschen, @​loshz in https://github.com/apollographql/router/pull/6151

Add fleet awareness schema metric (PR #​6283)

The router now supports the apollo.router.instance.schema metric for its fleet_detector plugin. It has two attributes: schema_hash and launch_id.

By @​loshz and @​nmoutschen in https://github.com/apollographql/router/pull/6283

Support client name for persisted query lists (PR #​6198)

The persisted query manifest fetched from Apollo Uplink can now contain a clientName field in each operation. Two operations with the same id but different clientName are considered to be distinct operations, and they may have distinct bodies.

The router resolves the client name by taking the first from the following that exists:

• Reading the apollo_persisted_queries::client_name context key that may be set by a router_service plugin
• Reading the HTTP header named by telemetry.apollo.client_name_header, which defaults to apollographql-client-name

If a client name can be resolved for a request, the router first tries to find a persisted query with the specified ID and the resolved client name.

If there is no operation with that ID and client name, or if a client name cannot be resolved, the router tries to find a persisted query with the specified ID and no client name specified. This means that existing PQ lists that don't contain client names will continue to work.

To learn more, go to persisted queries docs.

By @​glasser in https://github.com/apollographql/router/pull/6198

🐛 Fixes

Fix coprocessor empty body object panic (PR #​6398)

Previously, the router would panic if a coprocessor responds with an empty body object at the supergraph stage:

{
  ... // other fields
  "body": {} // empty object
}

This has been fixed in this release.

Note: the previous issue didn't affect coprocessors that responded with formed responses.

By @​BrynCooke in https://github.com/apollographql/router/pull/6398

Ensure cost directives are picked up when not explicitly imported (PR #​6328)

With the recent composition changes, importing @cost results in a supergraph schema with the cost specification import at the top. The @cost directive itself is not explicitly imported, as it's expected to be available as the default export from the cost link. In contrast, uses of @listSize to translate to an explicit import in the supergraph.

Old SDL link

@​link(
    url: "https://specs.apollo.dev/cost/v0.1"
    import: ["@​cost", "@​listSize"]
)

New SDL link

@​link(url: "https://specs.apollo.dev/cost/v0.1", import: ["@​listSize"])

Instead of using the directive names from the import list in the link, the directive names now come from SpecDefinition::directive_name_in_schema, which is equivalent to the change we made on the composition side.

By @​tninesling in https://github.com/apollographql/router/pull/6328

Fix query hashing algorithm (PR #​6205)

The router includes a schema-aware query hashing algorithm designed to return the same hash across schema updates if the query remains unaffected. This update enhances the algorithm by addressing various corner cases to improve its reliability and consistency.

By @​Geal in https://github.com/apollographql/router/pull/6205

Fix typo in persisted query metric attribute (PR #​6332)

The apollo.router.operations.persisted_queries metric reports an attribute when a persisted query was not found.
Previously, the attribute name was persisted_quieries.not_found, with one i too many. Now it's persisted_queries.not_found.

By @​goto-bus-stop in https://github.com/apollographql/router/pull/6332

Fix telemetry instrumentation using supergraph query selector (PR #​6324)

Previously, router telemetry instrumentation that used query selectors could log errors with messages such as this is a bug and should not happen.

These errors have now been fixed, and configurations with query selectors such as the following work properly:

telemetry:
  exporters:
    metrics:
      common:
        views:

### Define a custom view because operation limits are different than the default latency-oriented view of OpenTelemetry
          - name: oplimits.*
            aggregation:
              histogram:
                buckets:
                  - 0
                  - 5
                  - 10
                  - 25
                  - 50
                  - 100
                  - 500
                  - 1000
  instrumentation:
    instruments:
      supergraph:
        oplimits.aliases:
          value:
            query: aliases
          type: histogram
          unit: number
          description: "Aliases for an operation"
        oplimits.depth:
          value:
            query: depth
          type: histogram
          unit: number
          description: "Depth for an operation"
        oplimits.height:
          value:
            query: height
          type: histogram
          unit: number
          description: "Height for an operation"
        oplimits.root_fields:
          value:
            query: root_fields
          type: histogram
          unit: number
          description: "Root fields for an operation"

By @​bnjjj in https://github.com/apollographql/router/pull/6324

More consistent attributes on apollo.router.operations.persisted_queries metric (PR #​6403)

Version 1.28.1 added several unstable metrics, including apollo.router.operations.persisted_queries.

When an operation is rejected, Router includes a persisted_queries.safelist.rejected.unknown attribute on the metric. Previously, this attribute had the value true if the operation is logged (via log_unknown), and false if the operation is not logged. (The attribute is not included at all if the operation is not rejected.) This appears to have been a mistake, as you can also tell whether it is logged via the persisted_queries.logged attribute.

Router now only sets this attribute to true, and never to false. Note these metrics are unstable and will continue to change.

By @​glasser in https://github.com/apollographql/router/pull/6403

Drop experimental reuse fragment query optimization option (PR #​6354)

Drop support for the experimental reuse fragment query optimization. This implementation was not only very slow but also very buggy due to its complexity.

Auto generation of fragments is a much simpler (and faster) algorithm that in most cases produces better results. Fragment auto generation is the default optimization since v1.58 release.

By @​dariuszkuc in https://github.com/apollographql/router/pull/6353

📃 Configuration

Add version number to distributed query plan cache keys (PR #​6406)

The router now includes its version number in the cache keys of distributed cache entries. Given that a new router release may change how query plans are generated or represented, including the router version in a cache key enables the router to use separate cache entries for different versions.

If you have enabled distributed query plan caching, expect additional processing for your cache to update for this router release.

By @​SimonSapin in https://github.com/apollographql/router/pull/6406

🛠 Maintenance

Remove catch_unwind wrapper around the native query planner (PR #​6397)

As part of internal maintenance of the query planner, the
catch_unwind wrapper around the native query planner has been removed. This wrapper served as an extra safeguard for potential panics the native planner could produce. The
native query planner however no longer has any code paths that could panic. We have also
not witnessed a panic in the last four months, having processed 560 million real
user operations through the native planner.

This maintenance work also removes backtrace capture for federation errors, which
was used for debugging and is no longer necessary as we have the confidence in
the native planner's implementation.

By @​lrlna in https://github.com/apollographql/router/pull/6397

Deprecate various metrics (PR #​6350)

Several metrics have been deprecated in this release, in favor of OpenTelemetry-compatible alternatives:

• apollo_router_deduplicated_subscriptions_total - use the apollo.router.operations.subscriptions metric's subscriptions.deduplicated attribute.
• apollo_authentication_failure_count - use the apollo.router.operations.authentication.jwt metric's authentication.jwt.failed attribute.
• apollo_authentication_success_count - use the apollo.router.operations.authentication.jwt metric instead. If the authentication.jwt.failed attribute is absent or false, the authentication succeeded.
• apollo_require_authentication_failure_count - use the http.server.request.duration metric's http.response.status_code attribute. Requests with authentication failures have HTTP status code 401.
• apollo_router_timeout - this metric conflates timed-out requests from client to the router, and requests from the router to subgraphs. Timed-out requests have HTTP status code 504. Use the http.response.status_code attribute on the http.server.request.duration metric to identify timed-out router requests, and the same attribute on the http.client.request.duration metric to identify timed-out subgraph requests.

The deprecated metrics will continue to work in the 1.x release line.

By @​goto-bus-stop in https://github.com/apollographql/router/pull/6350

v1.58.1

Compare Source

[!IMPORTANT]
If you have enabled Distributed query plan caching, this release contains changes which necessarily alter the hashing algorithm used for the cache keys. On account of this, you should anticipate additional cache regeneration cost when updating between these versions while the new hashing algorithm comes into service.

🐛 Fixes

Particular supergraph telemetry customizations using the query selector do not error (PR #​6324)

Telemetry customizations like those featured in the request limits telemetry documentation now work as intended when using the query selector on the supergraph layer. Prior to this fix, this was sometimes causing a this is a bug and should not happen error, but is now resolved.

By @​bnjjj in https://github.com/apollographql/router/pull/6324

Native query planner now receives both "plan" and "path" limits configuration (PR #​6316)

The native query planner now correctly sets two experimental configuration options for limiting query planning complexity. These were previously available in the configuration and observed by the legacy planner, but were not being passed to the new native planner until now:

• supergraph.query_planning.experimental_plans_limit
• supergraph.query_planning.experimental_paths_limit

By @​goto-bus-stop in https://github.com/apollographql/router/pull/6316

v1.58.0

Compare Source

[!IMPORTANT]
If you have enabled Distributed query plan caching, this release contains changes which necessarily alter the hashing algorithm used for the cache keys. On account of this, you should anticipate additional cache regeneration cost when updating between these versions while the new hashing algorithm comes into service.

🚀 Features

Support DNS resolution strategy configuration (PR #​6109)

The router now supports a configurable DNS resolution strategy for the URLs of coprocessors and subgraphs.
The new option is called dns_resolution_strategy and supports the following values:

• ipv4_only - Only query for A (IPv4) records.
• ipv6_only - Only query for AAAA (IPv6) records.
• ipv4_and_ipv6 - Query for both A (IPv4) and AAAA (IPv6) records in parallel.
• ipv6_then_ipv4 - Query for AAAA (IPv6) records first; if that fails, query for A (IPv4) records.
• ipv4_then_ipv6(default) - Query for A (IPv4) records first; if that fails, query for AAAA (IPv6) records.

You can change the DNS resolution strategy applied to a subgraph's URL:

traffic_shaping:
  all:
    dns_resolution_strategy: ipv4_then_ipv6

You can also change the DNS resolution strategy applied to a coprocessor's URL:

coprocessor:
  url: http://coprocessor.example.com:8081
  client:
    dns_resolution_strategy: ipv4_then_ipv6

By @​IvanGoncharov in https://github.com/apollographql/router/pull/6109

Configuration options for HTTP/1 max headers and buffer limits (PR #​6194)

This update introduces configuration options that allow you to adjust the maximum number of HTTP/1 request headers and the maximum buffer size allocated for headers.

By default, the router accepts HTTP/1 requests with up to 100 headers and allocates ~400 KiB of buffer space to store them. If you need to handle requests with more headers or require a different buffer size, you can now configure these limits in the router's configuration file:

limits:
  http1_request_max_headers: 200
  http1_request_max_buf_size: 200kib

If you are using the router as a Rust crate, the http1_request_max_buf_size option requires the hyper_header_limits feature and also necessitates using Apollo's fork of the Hyper crate until the changes are merged upstream.
You can include this fork by adding the following patch to your Cargo.toml file:

[patch.crates-io]
"hyper" = { git = "https://github.com/apollographql/hyper.git", tag = "header-customizations-20241108" }

By @​IvanGoncharov in https://github.com/apollographql/router/pull/6194

Compress subgraph operations by generating fragments (PR #​6013)

The router now compresses operations sent to subgraphs by default by generating fragment
definitions and using them in the operation.

This change enables generate_query_fragments by default while disabling experimental_reuse_query_fragments. When enabled, experimental_reuse_query_fragments attempts to intelligently reuse the fragment definitions
from the original operation. However, fragment generation with generate_query_fragments is much faster and produces better outputs in most cases.

If you are relying on the shape of fragments in your subgraph operations or tests, you can opt out of the new algorithm with the configuration below.

Note: The subgraph operations generated by the query planner are not guaranteed consistent release over release. We strongly recommend against relying on the shape of planned subgraph operations, as new router features and optimizations will continuously affect it. We plan to remove experimental_reuse_query_fragments in a future release.

supergraph:
  generate_query_fragments: false
  experimental_reuse_query_fragments: true

By @​lrlna in https://github.com/apollographql/router/pull/6013

Add subgraph request id (PR #​5858)

The router now supports a subgraph request ID that is a unique string identifying a subgraph request and response. It allows plugins and coprocessors to keep some state per subgraph request by matching on this ID. It's available in coprocessors as subgraphRequestId and Rhai scripts as request.subgraph.id and response.subgraph.id.

By @​Geal in https://github.com/apollographql/router/pull/5858

Add extensions.service for all subgraph errors (PR #​6191)

For improved debuggability, the router now supports adding a subgraph's name as an extension to all errors originating from the subgraph.

If include_subgraph_errors is true for a particular subgraph, all errors originating in this subgraph will have the subgraph's name exposed as a service extension.

You can enable subgraph errors with the following configuration:

include_subgraph_errors:
  all: true # Propagate errors from all subgraphs

Note: This option is enabled by default by the router's dev mode.

Consequently, when a subgraph returns an error, it will have a service extension with the subgraph name as its value. The following example shows the extension for a products subgraph:

{
  "data": null,
  "errors": [
    {
      "message": "Invalid product ID",
      "path": [],
      "extensions": {
        "service": "products"
      }
    }
  ]
}

By @​IvanGoncharov in https://github.com/apollographql/router/pull/6191

Add @context support in the native query planner (PR #​6310)

The @context feature is now available in the native query planner.
This brings the native query planner to feature parity with the legacy query planner for all Federation v2 graphs. The native query planner can be enabled with the following configuration:

experimental_query_planner_mode: new

By @​clenfest, @​TylerBloom in https://github.com/apollographql/router/pull/6310

🐛 Fixes

Remove noisy demand control logs (PR #​6192)

Demand control no longer logs warnings when a subgraph response is missing a requested field.

By @​tninesling in https://github.com/apollographql/router/pull/6192

Renamed headers' original values can again be propagated (PR #​6281)

PR #​4535 introduced a regression where the following header propagation config would not work:

headers:
- propagate:
    named: a
    rename: b
- propagate:
    named: a
    rename: c

The goal of the original PR was to prevent multiple headers from being mapped to a single target header. However, it did not consider renames and instead prevented multiple mappings from the same source header.
The router now propagates headers properly and ensures that a target header is only propagated to once.

By @​BrynCooke in https://github.com/apollographql/router/pull/6281

Introspection response deduplication should always produce results (Issue #​6249)

To reduce CPU usage, query planning and introspection queries are deduplicated. In some cases, deduplicated introspection queries were not receiving their result. This issue has been fixed, and the router now sends results in all cases.

By @​Geal in https://github.com/apollographql/router/pull/6257

Don't log response data upon notification failure for subgraph batching (PR #​6150)

For a subgraph batching operation, the router now doesn't log the entire subgraph response when failing to notify a waiting batch participant. This saves the router from logging the large amount of data (PII and/or non-PII data) that a subgraph response may contain.

By @​garypen in https://github.com/apollographql/router/pull/6150

Move heavy computation to a thread pool with a priority queue (PR #​6247)

The router now avoids blocking threads when executing asynchronous code by using a thread pool with a priority queue.

This improves the performance of the following components that can take non-trivial amounts of CPU time:

• GraphQL parsing
• GraphQL validation
• Query planning
• Schema introspection

The size of the thread pool is based on the number of available CPU cores.

The thread pool replaces the router's prior implementation that used Tokio’s spawn_blocking.

apollo.router.compute_jobs.queued is a new gauge metric for the number of items in the thread pool's priority queue.

Note: when the native query planner is enabled, the dedicated queue of the legacy query planner is no longer used, so the apollo.router.query_planning.queued metric is no longer emitted.

By @​SimonSapin in https://github.com/apollographql/router/pull/6247

Limit the amount of GraphQL validation errors returned per response (PR #​6187)

When an invalid query is submitted, the router now returns at most one hundred GraphQL parsing and validation errors in a response. This prevents generating too large of a response for a nonsensical document.

By @​goto-bus-stop in https://github.com/apollographql/router/pull/6187

Remove placeholders from file upload query variables (PR #​6293)

Previously, file upload query variables in subgraph requests incorrectly contained internal placeholders.
According to the GraphQL Multipart Request Spec, these variables should be set to null.
This issue has been fixed by ensuring that the router complies with the specification and improving compatibility with subgraphs handling file uploads.

By @​IvanGoncharov in https://github.com/apollographql/router/pull/6293

Overhead processing metrics should exclude subgraph response time when deduplication is enabled (PR #​6207)

The router's calculated overhead processing time has been fixed, where the time spent waiting for the subgraph response of a deduplicated request had been incorrectly included.

By @​Geal in https://github.com/apollographql/router/pull/6207

Fix demand control panic for custom scalars that represent non-GraphQL-compliant JSON (PR #​6288)

Previously, a panic could be triggered in the router's demand control plugin with the following schema:

scalar ArbitraryJson

type MyInput {
    json: ArbitraryJson
}

type Query {
    fetch(args: MyInput): Int
}

Then, submitting the query

query FetchData(: ArbitraryJson) {
    fetch(args: {
        json: 
    })
}

and variables

{
    "myJsonValue": {
        "field.with.dots": 1
    }
}

During scoring, the demand control plugin would attempt to convert the variable structure into a GraphQL-compliant structure requiring valid GraphQL names as keys. The dot characters in the keys however would cause a panic.

With this fix, only the GraphQL compliant part of the input object is scored, and the arbitrary JSON marked by the custom scalar is scored as an opaque scalar (similar to how built-ins like Int or String are processed).

By @​tninesling in https://github.com/apollographql/router/pull/6288

Fix incorrect overriding of concrete type names with interface names when merging responses (PR #​6250)

When using @interfaceObject, differing pieces of data can come back with either concrete types or interface types depending on the source. Previously, receiving the data in a particular order could incorrectly result in the interface name of a type overwriting its concrete name.

To make the response merging order-agnostic, the router now checks the schema to ensure concrete types are not overwritten with interfaces or less specific types.

By @​tninesling in https://github.com/apollographql/router/pull/6250

🛠 Maintenance

Query planner cache key improvements (Issue #​5160)

Several performance improvements have been implemented for query plan cache key generation. In particular, the distributed cache's key format has changed, which adds prefixes to the different key segments to help in debugging.

By @​Geal in https://github.com/apollographql/router/pull/6206

Add entity caching invalidation configuration metrics (PR #​6286)

We've added metrics for our analytics to know if entity caching invalidation is enabled.

By @​bnjjj in https://github.com/apollographql/router/pull/6286

Avoid creating stub span for supergraph events if current span exists (PR #​6096)

The router optimized its telemetry implementation by not creating a redundant span when it already has a span available to use the span's extensions for supergraph events.

By @​bnjjj in https://github.com/apollographql/router/pull/6096

📚 Documentation

Clarify docs for authorization directive composition (PR #​6216)

The docs for authorization directive composition have been clarified, including corrected code examples.

By @​Meschreiber in https://github.com/apollographql/router/pull/6216

v1.57.1

Compare Source

🐛 Fixes

Progressive override: fix query planner cache warmup (PR #​6108)

This fixes an issue in progressive override where the override labels were not transmitted to the query planner during cache warmup. Queries were correctly using the overridden fields at first, but after an update, reverted to non overridden fields, and could not recover.

By @​Geal in https://github.com/apollographql/router/pull/6108

v1.57.0

Compare Source

[!IMPORTANT]
If you have enabled Distributed query plan caching, updates to the query planner in this release will result in query plan caches being re-generated rather than re-used. On account of this, you should anticipate additional cache regeneration cost when updating between these versions while the new query plans come into service.

🚀 Features

Remove legacy schema introspection (PR #​6139)

Schema introspection in the router now runs natively without JavaScript. We have high confidence that the new native implementation returns responses that match the previous Javascript implementation, based on differential testing: fuzzing arbitrary queries against a large schema, and testing a corpus of customer schemas against a comprehensive query.

Changes to the router's YAML configuration:

• The experimental_introspection_mode key has been removed, with the new mode as the only behavior in this release.
• The supergraph.query_planning.legacy_introspection_caching key is removed, with the behavior in this release now similar to what was false: introspection responses are not part of the query plan cache but instead in a separate, small in-memory—only cache.

When using the above deprecated configuration options, the router's automatic configuration migration will ensure that existing configuration continue to work until the next major version of the router. To simplify major upgrades, we recommend reviewing incremental updates to your YAML configuration by comparing the output of ./router config upgrade --config path/to/config.yaml with your existing configuration.

By @​SimonSapin in https://github.com/apollographql/router/pull/6139

Support new request_context selector for telemetry (PR #​6160)

The router supports a new request_context selector for telemetry that enables access to the supergraph schema ID.

You can configure the context to access the supergraph schema ID at the router service level:

telemetry:
  instrumentation:
    events:
      router:
        my.request_event:
          message: "my request event message"
          level: info
          on: request
          attributes:
            schema.id:
              request_context: "apollo::supergraph_schema_id" # The key containing the supergraph schema id

You can use the selector in any service at any stage. While this example applies to events attributes, the selector can also be used on spans and instruments.

By @​bnjjj in https://github.com/apollographql/router/pull/6160

Support reading and setting port on request URIs using Rhai (Issue #​5437)

Custom Rhai scripts in the router now support the request.uri.port and request.subgraph.uri.port functions for reading and setting URI ports. These functions enable you to update the full URI for subgraph fetches. For example:

fn subgraph_service(service, subgraph){
    service.map_request(|request|{
        log_info(``);
        if request.subgraph.uri.port == {} {
            log_info("Port is not explicitly set");
        }
        request.subgraph.uri.host = "api.apollographql.com";
        request.subgraph.uri.path = "/api/graphql";
        request.subgraph.uri.port = 1234;
        log_info(``);
    });
}

By @​lleadbet in https://github.com/apollographql/router/pull/5439

🐛 Fixes

Fix various edge cases for __typename field (PR #​6009)

The router now correctly handles the __typename field used on operation root types, even when the subgraph's root type has a name that differs from the supergraph's root type.

For example, given a query like this:

{
  ...RootFragment
}

fragment RootFragment on Query {
  __typename
  me {
    name
  }
}

Even if the subgraph's root type returns a __typename that differs from Query, the router will still use Query as the value of the __typename field.

This change also includes fixes for other edge cases related to the handling of __typename fields. For a detailed technical description of the edge cases that were fixed, please see this description.

By @​IvanGoncharov in https://github.com/apollographql/router/pull/6009

Support uri and method properties on router "request" objects in Rhai (PR #​6147)

The router now supports accessing request.uri and request.method properties from custom Rhai scripts. Previously, when trying to access request.uri and request.method on a router request in Rhai, the router would return error messages stating the properties were undefined.

An example Rhai script using these properties:

fn router_service(service) {
  let router_request_callback = Fn("router_request_callback");
  service.map_request(router_request_callback);
}

fn router_request_callback (request) {
  log_info(`Router Request... Host: , Path: `);
}

By @​andrewmcgivery in https://github.com/apollographql/router/pull/6114

Cost calculation for subgraph requests with named fragments (PR #​6162)

In some cases where subgraph GraphQL operations contain named fragments and abstract types, demand control used the wrong type for cost calculation, and could reject valid operations. Now, the correct type is used.

This fixes errors of the form:

Attempted to look up a field on type MyInterface, but the field does not exist

By @​goto-bus-stop in https://github.com/apollographql/router/pull/6162

Federation v2.9.3 (PR #​6161)

This release updates to Federation v2.9.3, with query planner fixes:

• Fixes a query planning bug where operation variables for a subgraph query wouldn't match what's used in that query.
• Fixes a query planning bug where directives applied to __typename may be omitted in the subgraph query.
• Fixes a query planning inefficiency where some redundant subgraph queries were not removed.
• Fixes a query planning inefficiency where some redundant inline fragments in @key/@requires selection sets were not optimized away.
• Fixes a query planning inefficiency where unnecessary subgraph jumps were being added when using @context/@fromContext.

By @​sachindshinde in https://github.com/apollographql/router/pull/6161

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.