v1.61.1

🐛 Fixes

Use correct default values on omitted OTLP endpoints (PR #6931)

Previously, when the configuration didn't specify an OTLP endpoint, the Router would always default to http://localhost:4318. However, port 4318 is the correct default only for the HTTP protocol, while port 4317 should be used for gRPC.

Additionally, all other telemetry defaults in the Router configuration consistently use 127.0.0.1 as the hostname rather than localhost.

With this change, the Router now uses:

• http://127.0.0.1:4317 as the default for gRPC protocol
• http://127.0.0.1:4318 as the default for HTTP protocol

This ensures protocol-appropriate port defaults and consistent hostname usage across all telemetry configurations.

By @IvanGoncharov in #6931

Separate entity keys and representation variables in entity cache key (Issue #6673)

This fix separates the entity keys and representation variable values in the cache key, to avoid issues with @requires for example.

By @bnjjj in #6888

🔒 Security

Add batching.maximum_size configuration option to limit maximum client batch size (PR #7005)

Add an optional maximum_size parameter to the batching configuration.

• When specified, the router will reject requests which contain more than maximum_size queries in the client batch.
• When unspecified, the router performs no size checking (the current behavior).

If the number of queries provided exceeds the maximum batch size, the entire batch fails with error code 422 (Unprocessable Content). For example:

{
  "errors": [
    {
      "message": "Invalid GraphQL request",
      "extensions": {
        "details": "Batch limits exceeded: you provided a batch with 3 entries, but the configured maximum router batch size is 2",
        "code": "BATCH_LIMIT_EXCEEDED"
      }
    }
  ]
}

By @carodewig in #7005

🔍 Debuggability

Add apollo.router.pipelines metrics (PR #6967)

When the router reloads, either via schema change or config change, a new request pipeline is created.
Existing request pipelines are closed once their requests finish. However, this may not happen if there are ongoing long requests that do not finish, such as Subscriptions.

To enable debugging when request pipelines are being kept around, a new gauge metric has been added:

• apollo.router.pipelines - The number of request pipelines active in the router
  • schema.id - The Apollo Studio schema hash associated with the pipeline.
  • launch.id - The Apollo Studio launch id associated with the pipeline (optional).
  • config.hash - The hash of the configuration

By @BrynCooke in #6967

Add apollo.router.open_connections metric (PR #7023)

To help users to diagnose when connections are keeping pipelines hanging around, the following metric has been added:

• apollo.router.open_connections - The number of request pipelines active in the router
  • schema.id - The Apollo Studio schema hash associated with the pipeline.
  • launch.id - The Apollo Studio launch id associated with the pipeline (optional).
  • config.hash - The hash of the configuration.
  • server.address - The address that the router is listening on.
  • server.port - The port that the router is listening on if not a unix socket.
  • state - Either active or terminating.

You can use this metric to monitor when connections are open via long running requests or keepalive messages.

By @BrynCooke in #7009

v2.1.0

🚀 Features

Connectors: support for traffic shaping (PR #6737)

Traffic shaping is now supported for connectors. To target a specific source, use the subgraph_name.source_name under the new connector.sources property of traffic_shaping. Settings under connector.all will apply to all connectors. deduplicate_query is not supported at this time.

Example config:

traffic_shaping:
  connector:
    all:
      timeout: 5s
    sources:
      connector-graph.random_person_api:
        global_rate_limit:
          capacity: 20
          interval: 1s
        experimental_http2: http2only
        timeout: 1s

By @andrewmcgivery in #6737

Connectors: Support TLS configuration (PR #6995)

Connectors now supports TLS configuration for using custom certificate authorities and utilizing client certificate authentication.

tls:
  connector:
    sources:
      connector-graph.random_person_api:
        certificate_authorities: ${file.ca.crt}
        client_authentication:
          certificate_chain: ${file.client.crt}
          key: ${file.client.key}

By @andrewmcgivery in #6995

Update JWT handling (PR #6930)

This PR updates JWT-handling in the AuthenticationPlugin;

• Users may now set a new config option config.authentication.router.jwt.on_error.
  • When set to the default Error, JWT-related errors will be returned to users (the current behavior).
  • When set to Continue, JWT errors will instead be ignored, and JWT claims will not be set in the request context.
• When JWTs are processed, whether processing succeeds or fails, the request context will contain a new variable apollo::authentication::jwt_status which notes the result of processing.

By @Velfi in #6930

Add batching.maximum_size configuration option to limit maximum client batch size (PR #7005)

Add an optional maximum_size parameter to the batching configuration.

• When specified, the router will reject requests which contain more than maximum_size queries in the client batch.
• When unspecified, the router performs no size checking (the current behavior).

If the number of queries provided exceeds the maximum batch size, the entire batch fails with error code 422 (Unprocessable Content). For example:

{
  "errors": [
    {
      "message": "Invalid GraphQL request",
      "extensions": {
        "details": "Batch limits exceeded: you provided a batch with 3 entries, but the configured maximum router batch size is 2",
        "code": "BATCH_LIMIT_EXCEEDED"
      }
    }
  ]
}

By @carodewig in #7005

Introduce PQ manifest hot_reload option for local manifests (PR #6987)

This change introduces a persisted_queries.hot_reload configuration option to allow the router to hot reload local PQ manifest changes.

If you configure local_manifests, you can set hot_reload to true to automatically reload manifest files whenever they change. This lets you update local manifest files without restarting the router.

persisted_queries:
  enabled: true
  local_manifests:
    - ./path/to/persisted-query-manifest.json
  hot_reload: true

Note: This change explicitly does not piggyback on the existing --hot-reload flag.

By @trevor-scheer in #6987

Add support to get/set URI scheme in Rhai (Issue #6897)

This adds support to read and write the scheme from the request.uri.scheme/request.subgraph.uri.scheme functions in Rhai,
enabling the ability to switch between http and https for subgraph fetches. For example:

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

By @starJammer in #6906

Add router config validate subcommand (PR #7016)

Adds new router config validate subcommand to allow validation of a router config file without fully starting up the Router.

./router config validate <path-to-config-file.yaml>

By @andrewmcgivery in #7016

Enable remote proxy downloads of the Router

This enables users without direct download access to specify a remote proxy mirror location for the GitHub download of
the Apollo Router releases.

By @LongLiveCHIEF in #6667

Add metric to measure cardinality overflow frequency (PR #6998)

Adds a new counter metric, apollo.router.telemetry.metrics.cardinality_overflow, that is incremented when the cardinality overflow log from opentelemetry-rust occurs. This log means that a metric in a batch has reached a cardinality of > 2000 and that any excess attributes will be ignored.

By @rregitsky in #6998

Add metrics for value completion errors (PR #6905)

When the router encounters a value completion error, it is not included in the GraphQL errors array, making it harder to observe. To surface this issue in a more obvious way, router now counts value completion error metrics via the metric instruments apollo.router.graphql.error and apollo.router.operations.error, distinguishable via the code attribute with value RESPONSE_VALIDATION_FAILED.

By @timbotnik in #6905

Add apollo.router.pipelines metrics (PR #6967)

When the router reloads, either via schema change or config change, a new request pipeline is created.
Existing request pipelines are closed once their requests finish. However, this may not happen if there are ongoing long requests that do not finish, such as Subscriptions.

To enable debugging when request pipelines are being kept around, a new gauge metric has been added:

• apollo.router.pipelines - The number of request pipelines active in the router
  • schema.id - The Apollo Studio schema hash associated with the pipeline.
  • launch.id - The Apollo Studio launch id associated with the pipeline (optional).
  • config.hash - The hash of the configuration

By @BrynCooke in #6967

Add apollo.router.open_connections metric (PR #7023)

To help users to diagnose when connections are keeping pipelines hanging around, the following metric has been added:

• apollo.router.open_connections - The number of request pipelines active in the router
  • schema.id - The Apollo Studio schema hash associated with the pipeline.
  • launch.id - The Apollo Studio launch id associated with the pipeline (optional).
  • config.hash - The hash of the configuration.
  • server.address - The address that the router is listening on.
  • server.port - The port that the router is listening on if not a unix socket.
  • http.connection.state - Either active or terminating.

You can use this metric to monitor when connections are open via long running requests or keepalive messages.

By @BrynCooke in #7023

Add span events to error spans for connectors and demand control plugin (PR #6727)

New span events have been added to trace spans which include errors. These span events include the GraphQL error code that relates to the error. So far, this only includes errors generated by connectors and the demand control plugin.

By @bonnici in #6727

Changes to experimental error metrics (PR #6966)

In 2.0.0, an experimental metric telemetry.apollo.errors.experimental_otlp_error_metrics was introduced to track errors with additional attributes. A few related changes are included here:

• Sending these metrics now also respects the subgraph's send flag e.g. telemetry.apollo.errors.subgraph.[all|(subgraph name)].send.
• A new configuration option telemetry.apollo.errors.subgraph.[all|(subgraph name)].redaction_policy has been added. This flag only applies when redact is set to true. When set to ErrorRedactionPolicy.Strict, error redaction will behave as it has in the past. Setting this to ErrorRedactionPolicy.Extended will allow the extensions.code value from subgraph errors to pass through redaction and be sent to Studio.
• A warning about incompatibility of error telemetry w...

v2.2.0-preview.0

2.2.0-preview.0

v2.1.0-rc.1

2.1.0-rc.1

v1.61.1-rc.0

1.61.1-rc.0

v2.1.0-rc.0

2.1.0-rc.0

v1.61.0 - LTS

This is an LTS release of Apollo Router

To find out more about our maintenance and support policy, please refer to our docs

🚀 Features

Query planner dry-run option (PR #6656)

This PR adds a new dry-run option to the Apollo-Expose-Query-Plan header value that emits the query plans back to Studio for visualizations. This new value will only emit the query plan, and abort execution. This can be helpful for tools like rover, where query plan generation is needed but not full runtime, or for potentially prewarming query plan caches out of band.

curl --request POST --include \
     --header 'Accept: application/json' \
     --header 'Apollo-Expose-Query-Plan: dry-run' \
     --url 'http://127.0.0.1:4000/' \
     --data '{"query": "{ topProducts { upc name } }"}'

By @aaronArinder and @lennyburdette in #6656.

Enable Remote Proxy Downloads

This enables users without direct download access to specify a remote proxy mirror location for the github download of
the Apollo Router releases.

By @LongLiveCHIEF in #6667

🐛 Fixes

Header propagation rules passthrough (PR #6690)

Header propagation contains logic to prevent headers from being propagated more than once. This was broken
in #6281 which always considered a header propagated regardless if a rule
actually matched.

This PR alters the logic so that a header is marked as fixed only when it's populated.

The following will now work again:

headers:
  all:
    request:
      - propagate:
          named: a
          rename: b
      - propagate:
          named: b

Note that defaulting a header WILL populate it, so make sure to include your defaults last in your propagation
rules.

headers:
  all:
    request:
      - propagate:
          named: a
          rename: b
          default: defaulted # This will prevent any further rule evaluation for header `b`
      - propagate:
          named: b

Instead, make sure that your headers are defaulted last:

headers:
  all:
    request:
      - propagate:
          named: a
          rename: b
      - propagate:
          named: b
          default: defaulted # OK

By @BrynCooke in #6690

Entity cache: fix directive conflicts in cache-control header (Issue #6441)

Unnecessary cache-control directives are created in cache-control header. The router will now filter out unnecessary values from the cache-control header when the request resolves. So if there's max-age=10, no-cache, must-revalidate, no-store, the expected value for the cache-control header would simply be no-store. Please see the MDN docs for justification of this reasoning: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#preventing_storing

By @bnjjj in #6543

Query Planning: fix __typename selections in sibling typename optimization

The query planner uses an optimization technique called "sibling typename", which attaches __typename selections to their sibling selections so the planner won't need to plan them separately.

Previously, when there were multiple identical selections and one of them has a __typename attached, the query planner could pick the one without the attachment, effectively losing a __typename selection.

Now, the query planner favors the one with a __typename attached without losing the __typename selection.

By @duckki in #6824

📃 Configuration

Promote experimental_otlp_tracing_sampler config to stable (PR #6070)

The router's otlp tracing sampler feature that was previously experimental is now generally available.

If you used its experimental configuration, you should migrate to the new configuration option:

• telemetry.apollo.experimental_otlp_tracing_sampler is now telemetry.apollo.otlp_tracing_sampler

The experimental configuration option is now deprecated. It remains functional but will log warnings.

By @garypen in #6070

Promote experimental_local_manifess config for persisted queries to stable

The experimental_local_manifests PQ configuration option is being promoted to stable. This change updates the configuration option name and any references to it, as well as the related documentation. The experimental_ usage remains valid as an alias for existing usages.

By @trevor-scheer in #6564

🛠 Maintenance

Reduce demand control allocations on start/reload (PR #6754)

When demand control is enabled, the router now preallocates capacity for demand control's processed schema and shrinks to fit after processing. When it's disabled, the router skips the type processing entirely to minimize startup impact.

By @tninesling in #6754

v1.61.0-rc.0

1.61.0-rc.0

v2.0.0

This is a major release of the router containing significant new functionality and improvements to behaviour, resulting in more predictable resource utilisation and decreased latency.

Router 2.0.0 introduces general availability of Apollo Connectors, helping integrate REST services in router deployments.

This entry summarizes the overall changes in 2.0.0. To learn more details, go to the What's New in router v2.x page.

To upgrade to this version, follow the upgrading from router 1.x to 2.x guide.

❗ BREAKING CHANGES ❗

In order to make structural improvements in the router and upgrade some of our key dependencies, some breaking changes were introduced in this major release. Most of the breaking changes are in the areas of configuration and observability. All details on what's been removed and changed can be found in the upgrade guide.

🚀 Features

Router 2.0.0 comes with many new features and improvements. While all the details can be found in the What's New guide, the following features are the ones we are most excited about.

Simplified integration of REST services using Apollo Connectors. Apollo Connectors are a declarative programming model for GraphQL, allowing you to plug your existing REST services directly into your graph. Once integrated, client developers gain all the benefits of GraphQL, and API owners gain all the benefits of GraphOS, including incorporation into a supergraph for a comprehensive, unified view of your organization's data and services. This detailed guide outlines how to configure connectors with the router. Moving from Connectors Preview can be accomplished by following the steps in the Connectors GA upgrade guide.

Predictable resource utilization and availability with back pressure. Back pressure was not maintained in router 1.x, which meant all requests were being accepted by the router. This resulted in issues for routers which are accepting high levels of traffic. Router 2.0.0 improves the handling of back pressure so that traffic shaping measures are more effective while also improving integration with telemetry. Improvements to back pressure then allows for significant improvements in traffic shaping, which improves router's ability to observe timeout and traffic shaping restrictions correctly. You can read about traffic shaping changes in this section of the upgrade guide.

Metrics now all follow OpenTelemetry naming conventions. Some of router's earlier metrics were created before the introduction of OpenTelemetry, resulting in naming inconsistencies. Along with standardising metrics to OpenTelemetry, Apollo operation usage reporting now also defaults to using OpenTelemetry in router 2.0.0. Quite a few existing metrics had to be changed in order to do this properly and correctly, and we encourage you to carefully read through the upgrade guide for all the metrics changes.

Improved validation of CORS configurations, preventing silent failures. While CORS configuration did not change in router 2.0.0, we did improve CORS value validation. This results in things like invalid regex or unknown allow_methods returning errors early and preventing starting the router.

Documentation for context keys, improving usability for advanced customers. Router 2.0.0 creates consistent naming semantics for request context keys, which are used to share data across internal router pipeline stages. If you are relying on context entries in rust plugins, rhai scripts, coprocessors, or telemetry selectors, please refer to this section to see what keys changed.

📃 Configuration

Some changes to router configuration options were necessary in this release. Descriptions for both breaking changes to previous configuration and configuration for new features can be found in the upgrade guide).

🛠 Maintenance

Many external Rust dependencies (crates) have been updated to modern versions where possible. As the Rust ecosystem evolves, so does the router. Keeping these crates up to date helps keep the router secure and stable.

Major upgrades in this version include:

• axum
• http
• hyper
• opentelemetry
• redis

v2.0.0-rc.0

2.0.0-rc.0