Skip to content

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented May 18, 2024

Coming soon: The Renovate bot (GitHub App) will be renamed to Mend. PRs from Renovate will soon appear from 'Mend'. Learn more here.

This PR contains the following updates:

Package Change Age Adoption Passing Confidence Type Update
@apollo/client (source) 3.14.0 -> 4.0.5 age adoption passing confidence dependencies major
@apollo/server (source) 4.12.2 -> 5.0.0 age adoption passing confidence dependencies major
apollo-router 1.45.0 -> 2.0.0 age adoption passing confidence dependencies major
ghcr.io/apollographql/router v1.61.10 -> v2.7.0 age adoption passing confidence major
com.apollographql.federation:federation-graphql-java-support 4.5.0 -> 5.4.0 age adoption passing confidence dependencies major

Release Notes

apollographql/apollo-client (@​apollo/client)

v4.0.5

Compare Source

Patch Changes

v4.0.4

Compare Source

Patch Changes
  • #​12892 db8a04b Thanks @​jerelmiller! - Prevent unhandled rejections from the promise returned by calling the mutate function from the useMutation hook.

  • #​12899 5352c12 Thanks @​phryneas! - Fix an issue when invariant is called by external libraries when no dev error message handler is loaded.

  • #​12895 71f2517 Thanks @​jerelmiller! - Support skipToken with useQuery to provide a more type-safe way to skip query execution.

    import { skipToken, useQuery } from "@​apollo/client/react";
    
    // Use `skipToken` in place of `skip: true` for better type safety
    // for required variables
    const { data } = useQuery(QUERY, id ? { variables: { id } } : skipToken);

    Note: this change is provided as a patch within the 4.0 minor version because the changes to TypeScript validation with required variables in version 4.0 made using the skip option more difficult.

  • #​12900 c0d5be7 Thanks @​phryneas! - Use named export equal instead of default from "@​wry/equality"

v4.0.3

Compare Source

Patch Changes

v4.0.2

Compare Source

Patch Changes

v4.0.1

Compare Source

Patch Changes
  • #​12876 b00f231 Thanks @​phryneas! - Fix CJS build output for invariantErrorCodes

  • #​12866 0d1614a Thanks @​jerelmiller! - Export isNetworkStatusInFlight from @apollo/client/utilities. Add isNetworkStatusSettled to @apollo/client/utilities and re-export it from @apollo/client with a deprecation.

v4.0.0

Compare Source

apollographql/apollo-server (@​apollo/server)

v5.0.0

Compare Source

BREAKING CHANGES

Apollo Server v5 has very few breaking API changes. It is a small upgrade focused largely on adjusting which versions of Node.js and Express are supported.

Read our migration guide for more details on how to update your app.

  • Dropped support for Node.js v14, v16, and v18, which are no longer under long-term support from the Node.js Foundation. Apollo Server 5 supports Node.js v20 and later; v24 is recommended. Ensure you are on a non-EOL version of Node.js before upgrading Apollo Server.
  • Dropped support for versions of the graphql library older than v16.11.0. (Apollo Server 4 supports graphql v16.6.0 or later.) Upgrade graphql before upgrading Apollo Server.
  • Express integration requires a separate package. In Apollo Server 4, you could import the Express 4 middleware from @apollo/server/express4, or you could import it from the separate package @as-integrations/express4. In Apollo Server 5, you must import it from the separate package. You can migrate your server to the new package before upgrading to Apollo Server 5. (You can also use @as-integrations/express5 for a middleware that works with Express 5.)
  • Usage Reporting, Schema Reporting, and Subscription Callback plugins now use the Node.js built-in fetch implementation for HTTP requests by default, instead of the node-fetch npm package. If your server uses an HTTP proxy to make HTTP requests, you need to configure it in a slightly different way. See the migration guide for details.
  • The server started with startStandaloneServer no longer uses Express. This is mostly invisible, but it does set slightly fewer headers. If you rely on the fact that this server is based on Express, you should explicitly use the Express middleware.
  • The experimental support for incremental delivery directives @defer and @stream (which requires using a pre-release version of graphql v17) now explicitly only works with version 17.0.0-alpha.2 of graphql. Note that this supports the same incremental delivery protocol implemented by Apollo Server 4, which is not the same protocol in the latest alpha version of graphql. As this support is experimental, we may switch over from "only alpha.2 is supported" to "only a newer alpha or final release is supported, with a different protocol" during the lifetime of Apollo Server 5.
  • Apollo Server is now compiled by the TypeScript compiler targeting the ES2023 standard rather than the ES2020 standard.
  • Apollo Server 5 responds to requests with variable coercion errors (eg, if a number is passed in the variables map for a variable declared in the operation as a String) with a 400 status code, indicating a client error. This is also the behavior of Apollo Server 3. Apollo Server 4 mistakenly responds to these requests with a 200 status code by default; we recommended the use of the status400ForVariableCoercionErrors: true option to restore the intended behavior. That option now defaults to true.
  • The unsafe precomputedNonce option to landing page plugins (which was only non-deprecated for 8 days) has been removed.
Patch Changes

There are a few other small changes in v5:

  • #​8076 5b26558 Thanks @​valters! - Fix some error logs to properly call logger.error or logger.warn with this set. This fixes errors or crashes from logger implementations that expect this to be set properly in their methods.

  • #​7515 100233a Thanks @​trevor-scheer! - ApolloServerPluginSubscriptionCallback now takes a fetcher argument, like the usage and schema reporting plugins. The default value is Node's built-in fetch.

  • Updated dependencies [100233a]:

apollographql/router (apollo-router)

v2.7.0

Compare Source

🚀 Features

Add ResponseErrors selector to router response (PR #​7882)

The ResponseErrors selector in telemetry configurations captures router response errors, enabling you to log errors encountered at the router service layer. This selector enhances logging by allowing you to log only router errors instead of the entire router response body, reducing noise in your telemetry data.

telemetry:
  instrumentation:
    events:
      router:
        router.error:
          attributes:
            "my_attribute":
              response_errors: "$.[0]"

### Examples: "$.[0].message", "$.[0].locations", "$.[0].extensions", etc.

By @​Aguilarjaf in #​7882

🐛 Fixes

_entities Apollo error metrics missing service attribute (PR #​8153)

The error counting feature introduced in v2.5.0 caused _entities errors from subgraph fetches to no longer report a service (subgraph or connector) attribute. This incorrectly categorized these errors as originating from the router instead of their actual service in Apollo Studio.

The service attribute is now correctly included for _entities errors.

By @​rregitsky in #​8153

WebSocket connection cleanup for subscriptions (PR #​8104)

A regression introduced in v2.5.0 caused WebSocket connections to subgraphs to remain open after all client subscriptions ended. This led to unnecessary resource usage and connections not being cleaned up until a new event was received.

The router now correctly closes WebSocket connections to subgraphs when clients disconnect from subscription streams.

By @​bnjjj in #​8104

OTLP metrics Up/Down counter drift (PR #​8174)

When using OTLP metrics export with delta temporality configured, UpDown counters could exhibit drift issues where counter values became inaccurate over time. This occurred because UpDown counters were incorrectly exported as deltas instead of cumulative values.

UpDown counters now export as aggregate values according to the OpenTelemetry specification.

By @​BrynCooke in #​8174

WebSocket subscription connection_error message handling (Issue #​6138)

The router now correctly processes connection_error messages from subgraphs that don't include an id field. Previously, these messages were ignored because the router incorrectly required an id field. According to the graphql-transport-ws specification, connection_error messages only require a payload field.

The id field is now optional for connection_error messages, allowing underlying error messages to propagate to clients when connection failures occur.

By @​jeffutter in #​8189

Add Helm chart support for deployment annotations (PR #​8164)

The Helm chart now supports customizing annotations on the deployment itself using the deploymentAnnotations value. Previously, you could only customize pod annotations with podAnnotations.

By @​glasser in #​8164

Uncommon query planning error with interface object types (PR #​8109)

An uncommon query planning error has been resolved: "Cannot add selection of field X to selection set of parent type Y that is potentially an interface object type at runtime". The router now handles __typename selections from interface object types correctly, as these selections are benign even when unnecessary.

By @​duckki in #​8109

Connection shutdown race condition during hot reload (PR #​8169)

A race condition during hot reload that occasionally left connections in an active state instead of terminating has been fixed. This issue could cause out-of-memory errors over time as multiple pipelines remained active.

Connections that are opening during shutdown now immediately terminate.

By @​BrynCooke in #​8169

Persisted Query usage reporting for safelisted operation body requests (PR #​8168)

Persisted Query metrics now include operations requested by safelisted operation body. Previously, the router only recorded metrics for operations requested by ID.

By @​bonnici in #​8168

📃 Configuration

Separate Apollo telemetry batch processor configurations (PR #​8258)

Apollo telemetry configuration now allows separate fine-tuning for metrics and traces batch processors. The configuration has changed from:

telemetry:
  apollo:
    batch_processor:
      scheduled_delay: 5s
      max_export_timeout: 30s
      max_export_batch_size: 512
      max_concurrent_exports: 1
      max_queue_size: 2048

To:

telemetry:
  apollo:
    tracing:

### Config for Apollo OTLP and  Apollo usage report traces
      batch_processor:
        max_export_timeout: 130s
        scheduled_delay: 5s
        max_export_batch_size: 512
        max_concurrent_exports: 1
        max_queue_size: 2048
        
    metrics:

### Config for Apollo OTLP metrics. 
      otlp:
        batch_processor:
          scheduled_delay: 13s # This does not apply config gauge metrics, which have a non-configurable scheduled_delay.
          max_export_timeout: 30s

### Config for Apollo usage report metrics.
      usage_reports:
        batch_processor:
          max_export_timeout: 30s
          scheduled_delay: 5s
          max_queue_size: 2048

The old telemetry.apollo.batch_processor configuration will be used if you don't specify these new values. The router displays the configuration being used in an info-level log message at startup.

By @​bonnici in #​8258

Promote Subgraph Insights metrics flag to preview (PR #​8200)

The subgraph_metrics configuration flag that powers Apollo Studio's Subgraph Insights feature has been promoted from experimental to preview. The flag name has been updated from experimental_subgraph_metrics to preview_subgraph_metrics:

telemetry:
  apollo:
    preview_subgraph_metrics: true

By @​rregitsky in #​8200

v2.6.2

Compare Source

🐛 Fixes

Connection shutdown sometimes fails during hot-reload (PR #​8169)

A race condition in connection shutdown during a hot reload event occasionally left some connections in an active state instead of entering terminating state. This could cause out-of-memory errors over time as multiple pipelines remained active.

Connections that open during shutdown now immediately terminate.

By @​BrynCooke in #​8169

v2.6.1

Compare Source

🐛 Fixes

_entities Apollo Error Metrics Missing Service Attribute (PR #​8153)

The error counting feature introduced in v2.5.0 (PR #​7712) caused a bug where _entities errors from subgraph fetches no longer included a service (subgraph or connector) attribute. This incorrectly categorized these errors as originating from the router instead of their actual service in the Apollo Studio UI.

This fix restores the missing service attribute.

By @​rregitsky in #​8153

Deduplication and WebSocket stream termination (PR #​8104)

Fixed a regression introduced in v2.5.0, where WebSocket connections to subgraphs would remain open after all client subscriptions were closed. This could lead to unnecessary resource usage and connections not being properly cleaned up until a new event was received.

Previously, when clients disconnected from subscription streams, the router would correctly close client connections but would leave the underlying WebSocket connection to the subgraph open indefinitely in some cases.

By @​bnjjj in #​8104

Make the id field optional for WebSocket subscription connection_error messages (Issue #​6138)

Fixed a Subscriptions over WebSocket issue where connection_error messages from subgraphs would be swallowed by the router because they incorrectly required an id field. According to the graphql-transport-ws specification (one of two transport specifications we provide support for), connection_error messages only require a payload field, not an id field. The id field in is now optional which will allow the underlying error message to propagate to clients when underlying connection failures occur.

By @​jeffutter in #​8189

Enable annotations on deployments via Helm Chart (PR #​8164)

The Helm chart previously did not allow customization of annotations on the deployment itself (as opposed to the pods within it, which is done with podAnnotations); this can now be done with the deploymentAnnotations value.

By @​glasser in #​8164

v2.6.0

Compare Source

🚀 Features

[Subgraph Insights] Experimental Apollo Subgraph Fetch Histogram (PR #​8013, PR #​8045)

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 #​8013 and #​8045

Redis cache metrics (PR #​7920)

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 connections
  • apollo.router.cache.redis.command_queue_length: Commands waiting to be sent to Redis, indicates if Redis is keeping up with demand
  • apollo.router.cache.redis.commands_executed: Total number of Redis commands executed
  • apollo.router.cache.redis.redelivery_count: Commands retried due to connection issues
  • apollo.router.cache.redis.errors: Redis errors by type, to help diagnose authentication, network, and configuration problems

Experimental performance metrics:

  • experimental.apollo.router.cache.redis.network_latency_avg: Average network latency to Redis
  • experimental.apollo.router.cache.redis.latency_avg: Average Redis command execution time
  • experimental.apollo.router.cache.redis.request_size_avg: Average request payload size
  • experimental.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 #​7920

Granular license enforcement (PR #​7917)

The router license functionality now allows granular specification of features enabled to support current and future pricing plans.

By @​DMallare in #​7917

Additional Connector Custom Instrument Selectors (PR #​8045)

This adds new custom instrument selectors for Connectors and enhances some existing selectors. The new selectors are:

  • supergraph_operation_name
    • The supergraph's operation name
  • supergraph_operation_kind
    • The supergraph's operation type (e.g. query, mutation, subscription)
  • request_context
    • Takes the value of the given key on the request context
  • connector_on_response_error
    • Returns true when the response does not meet the is_successful condition. Or, if that condition is not set,
      returns true when the response has a non-200 status code

These selectors were modified to add additional functionality:

  • connector_request_mapping_problems
    • Adds a new boolean variant that will return true when a mapping problem exists on the request
  • connector_response_mapping_problems
    • Adds a new boolean variant that will return true when a mapping problem exists on the response

By @​rregitsky in #​8045

Enable jemalloc on MacOS (PR #​8046)

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 #​8046

🐛 Fixes

Entity caching: fix inconsistency in cache-control header handling (PR #​7987)

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 #​7987

Query planning errors with progressive override on interface implementations (PR #​7929)

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:

  • Interface implementations local to a subgraph
  • Progressive override directives on both the implementing type and its fields
  • Queries that traverse through the overridden interface implementations

The router will now successfully plan and execute queries that previously resulted in query planning errors.

By @​TylerBloom in #​7929

Reliably distinguish GraphQL errors and transport errors in subscriptions (PR #​7901)

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 #​7901

📚 Documentation

Update Documentation To Add DockerHub References

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 #​8054

v2.5.0

Compare Source

🚀 Features

Introduce per-origin CORS policies (PR #​7853)

Configuration can now specify different Cross-Origin Resource Sharing (CORS) rules for different origins using the cors.policies key. See the CORS documentation for details.

cors:
  policies:

### The default CORS options work for Studio.
    - origins: ["https://studio.apollographql.com"]

### Specific config for trusted origins
    - match_origins: ["^https://(dev|staging|www)?\\.my-app\\.(com|fr|tn)$"]
      allow_credentials: true
      allow_headers: ["content-type", "authorization", "x-web-version"]

### Catch-all for untrusted origins
    - origins: ["*"]
      allow_credentials: false
      allow_headers: ["content-type"]

By @​Velfi in #​7853

jemalloc metrics (PR #​7735)

This PR adds the following new metrics when running the router on Linux with its default global-allocator feature:

By @​Velfi in #​7735

🐛 Fixes

Coprocessor: improve handling of invalid GraphQL responses with conditional validation (PR #​7731)

The router was creating invalid GraphQL responses internally, especially when subscriptions terminate. When a coprocessor is configured, it validates all responses for correctness, causing errors to be logged when the router generates invalid internal responses. This affects the reliability of subscription workflows with coprocessors.

Fix handling of invalid GraphQL responses returned from coprocessors, particularly when used with subscriptions. Added conditional response validation and improved testing to ensure correctness. Added the response_validation configuration option at the coprocessor level to enable the response validation (by default it's enabled).

By @​BrynCooke in #​7731

Fix deduplicated subscriptions hanging when one subscription closes (PR #​7879)

Fixes a regression introduced in v1.50.0. When multiple client subscriptions are deduped onto a single subgraph subscription in WebSocket passthrough mode, and the first client subscription closes, the Router would close the subgraph subscription. The other deduplicated subscriptions would then silently stop receiving events.

Now outgoing subscriptions to subgraphs are kept open as long as any client subscription uses them.

By @​bnjjj in #​7879

Fix several hot reload issues with subscriptions (PR #​7746)

When a hot reload is triggered by a configuration change, the router attempted to apply updated configuration to open subscriptions. This could cause excessive logging.

When a hot reload was triggered by a schema change, the router closed subscriptions with a SUBSCRIPTION_SCHEMA_RELOAD error. This happened before the new schema was fully active and warmed up, so clients could reconnect to the old schema, which should not happen.

To fix these issues, a configuration and a schema change now have the same behavior. The router waits for the new configuration and schema to be active, and then closes all subscriptions with a SUBSCRIPTION_SCHEMA_RELOAD/SUBSCRIPTION_CONFIG_RELOAD error, so clients can reconnect.

By @​goto-bus-stop and @​bnjjj in #​7777

Fix error when removing non-UTF-8 headers with Rhai plugin (PR #​7801)

When trying to remove non-UTF-8 headers from a Rhai plugin, users were faced with an unhelpful error. Now, non-UTF-8 values will be lossy converted to UTF-8 when accessed from Rhai. This change affects get, get_all, and remove operations.

By @​Velfi in #​7801

Query planning errors with progressive override on interface implementations (PR #​7929)

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:

  • Interface implementations local to a subgraph
  • Progressive override directives on both the implementing type and its fields
  • Queries that traverse through the overridden interface implementations

The router will now successfully plan and execute queries that previously resulted in query planning errors.

By @​TylerBloom in #​7929

Fix startup hang with an empty Persisted Queries list (PR #​7831)

When the Persisted Queries feature is enabled, the router no longer hangs during startup when using a GraphOS account with no Persisted Queries manifest.

Remove @ from error paths (Issue #​4548)

When a subgraph returns an unexpected response (ie not a body with at least one of errors or data), the errors surfaced by the router include an @ in the path which indicates an error applied to all elements in the array. This is not a behavior defined in the GraphQL spec and is not easily parsed.

This fix expands the @ symbol to reflect all paths that the error applies to.

Example

Consider a federated graph with two subgraphs, products and inventory, and a topProducts query which fetches a list of products from products and then fetches an inventory status for each product.

A successful response might look like:

{
    "data": {
        "topProducts": [
            {"name": "Table", "inStock": true},
            {"name": "Chair", "inStock": false}
        ]
    }
}

Prior to this change, if the inventory subgraph returns a malformed response, the router response would look like:

{
    "data": {"topProducts": [{"name": "Table", "inStock": null}, {"name": "Chair", "inStock": null}]}, 
    "errors": [
        {
            "message": "service 'inventory' response was malformed: graphql response without data must contain at least one error", 
            "path": ["topProducts", "@​"], 
            "extensions": {"service": "inventory", "reason": "graphql response without data must contain at least one error", "code": "SUBREQUEST_MALFORMED_RESPONSE"}
        }
    ]
}

With this change, the response will look like:

{
    "data": {"topProducts": [{"name": "Table", "inStock": null}, {"name": "Chair", "inStock": null}]},
    "errors": [
        {
            "message": "service 'inventory' response was malformed: graphql response without data must contain at least one error",
            "path": ["topProducts", 0],
            "extensions": {"service": "inventory", "reason": "graphql response without data must contain at least one error", "code": "SUBREQUEST_MALFORMED_RESPONSE"}
        },
        {
            "message": "service 'inventory' response was malformed: graphql response without data must contain at least one error",
            "path": ["topProducts", 1],
            "extensions": {"service": "inventory", "reason": "graphql response without data must contain at least one error", "code": "SUBREQUEST_MALFORMED_RESPONSE"}
        }
    ]
}

The above examples reflect the behavior with include_subgraph_errors = true; if include_subgraph_errors is false:

{
    "data": {"topProducts": [{"name": "Table", "inStock": null}, {"name": "Chair", "inStock": null}]},
    "errors": [
        {
            "message": "Subgraph errors redacted",
            "path": ["topProducts", 0]
        },
        {
            "message": "Subgraph errors redacted",
            "path": ["topProducts", 1]
        }
    ]
}

By @​carodewig in #​7684

Remove use of APOLLO_TELEMETRY_DISABLED from the fleet detector plugin (PR #​7907)

The APOLLO_TELEMETRY_DISABLED environment variable only disables anonymous telemetry, it was never meant for disabling identifiable telemetry. This includes metrics from the fleet detection plugin.

By @​DMallare in #​7907

v2.4.0

Compare Source

🚀 Features

Support JWT audience (aud) validation (PR #​7578)

The router now supports JWT audience (aud) validation. This allows the router to ensure that the JWT is intended
for the specific audience it is being used with, enhancing security by preventing token misuse across different audiences.

The following sample configuration will validate the JWT's aud claim against the specified audiences and ensure a match with either https://my.api or https://my.other.api. If the aud claim does not match either of those configured audiences, the router will reject the request.

authentication:
 router:
   jwt:
     jwks: # This key is required.
       - url: https://dev-zzp5enui.us.auth0.com/.well-known/jwks.json
         issuers: # optional list of issuers
           - https://issuer.one
           - https://issuer.two
         audiences: # optional list of audiences
           - https://my.api
           - https://my.other.api
         poll_interval: <optional poll interval>
         headers: # optional list of static headers added to the HTTP request to the JWKS URL
           - name: User-Agent
             value: router

### These keys are optional. Default values are shown.
     header_name: Authorization
     header_value_prefix: Bearer
     on_error: Error

### array of alternative token sources
     sources:
       - type: header
         name: X-Authorization
         value_prefix: Bearer
       - type: cookie
         name: authz

By @​Velfi in #​7578

Prioritize existing requests over query parsing and planning during "warm up" (PR #​7223)

The router warms up its query planning cache during a hot reload. This change decreases the priority
of warm up tasks in the compute job queue to reduce the impact of warmup on serving requests.

This change adds new values to the job.type dimension of the following metrics:

  • apollo.router.compute_jobs.duration - A histogram of time spent in the compute pipeline by the job, including the queue and query planning.
    • job.type: (query_planning, query_parsing, introspection, query_planning_warmup, query_parsing_warmup)
    • job.outcome: (executed_ok, executed_error, channel_error, rejected_queue_full, abandoned)
  • apollo.router.compute_jobs.queue.wait.duration - A histogram of time spent in the compute queue by the job.
    • job.type: (query_planning, query_parsing, introspection, query_planning_warmup, query_parsing_warmup)
  • apollo.router.compute_jobs.execution.duration - A histogram of time spent to execute job (excludes time spent in the queue).
    • job.type: (query_planning, query_parsing, introspection, query_planning_warmup, query_parsing_warmup)
  • apollo.router.compute_jobs.active_jobs - A gauge of the number of compute jobs being processed in parallel.
    • job.type: (query_planning, query_parsing, introspection, query_planning_warmup, query_parsing_warmup)

By @​carodewig in #​7223

Persisted queries: include operation name in PERSISTED_QUERY_NOT_IN_LIST error for debuggability (PR #​7768)

When persisted query safelisting is enabled and a request has an unknown PQ ID, the GraphQL error now has the extension field operation_name containing the GraphQL operation name (if provided explicitly in the request). Note that this only applies to the PERSISTED_QUERY_NOT_IN_LIST error returned when manifest-based PQs are enabled, APQs are disabled, and the request contains an operation ID that is not in the list.

By @​glasser in #​7768

Introduce cooperative cancellation for query planning

The cooperative cancellation feature allows the router to gracefully handle query planning timeouts and cancellations, improving resource utilization.

The mode can be set to measure or enforce. We recommend starting with measure. In measure mode, the router will measure the time taken for query planning and emit metrics accordingly. In enforce mode, the router will cancel query planning operations that exceed the specified timeout.

To observe this behavior, the router telemetry has been updated:

  • Add an outcome attribute to the apollo.router.query_planning.plan.duration metric
  • Add an outcome attribute to the query_planning span

Below is a sample configuration to configure cooperative cancellation in measure mode:

supergraph:
  query_planning:
    experimental_cooperative_cancellation:
      enabled: true
      mode: measure
      timeout: 1s

By @​Velfi in #​7604

🐛 Fixes

Align on_graphql_error selector with subgraph_on_graphql_error (PR #​7676)

The on_graphql_error selector will now return true or false, in alignment with the subgraph_on_graphql_error selector. Previously, the selector would return true or None.

By @​carodewig in #​7676

Return valid GraphQL response when performing a websocket handshake (PR #​7680)

PR #​7141 added checks on GraphQL responses returned from coprocessors to ensure compliance with GraphQL specifications. This surfaced an issue where subscription responses over websockets could omit the required data field during the handshake, resulting in invalid GraphQL response payloads. All websocket subscription responses will now return a valid GraphQL response when doing the websocket handshake.

By @​bnjjj in #​7680

Fix SigV4 configuration handling (PR #​7726)

Fixed an issue introduced in Router 2.3.0 where some SigV4 configurations would fail to start, preventing communication with SigV4-enabled services.

By @​dylan-apollo in #​7726

Improve error message for invalid variables (Issue #​2984)

When a variable in a GraphQL request is missing or contains an invalid value, the router now returns more useful error messages. Example:

-invalid type for variable: 'x'
+invalid input value at x.coordinates[0].longitude: found JSON null for GraphQL Float!

By @​SimonSapin in #​7567

Support exporting resources on all Prometheus metrics (PR #​7394)

By default, the Prometheus metrics exporter will only export resources as target_info metrics, not inline on every metric. Now, you can add resources to every metric by setting resource_selector to all (default is none).

telemetry:
  exporters:
    metrics:
      common:
        resource:
          "test-resource": "test"
      prometheus:
        enabled: true
        resource_selector: all # This will add resources on every metrics

Note: this change only affects Prometheus, not OTLP.

By @​bnjjj in #​7394

Forbid unknown @link directives for supergraph schemas where purpose is EXECUTION or SECURITY

The legacy JavaScript query planner forbid any usage of unknown @link specs in supergraph schemas with either EXECUTION or SECURITY value set for the for argument (aka, the spec's "purpose"). This behavior had not been ported to the native query planner previously. This PR implements the expected behavior in the native query planner.

By @​duckki in #​7587

Supergraph stage correctly receives on_graphql_error selector (PR #​7669)

The on_graphql_error selector will now correctly fire on the supergraph stage; previously it only worked on the router stage.

By @​carodewig in #​7669

Invalid type condition in @defer fetch

The query planner was adding an inline spread (...) conditioned on the Query type in deferred subgraph fetch queries. Such a query would be invalid in the subgraph when the subgraph schema renamed the root query type to somethhing other than Query. The fix removes the root type condition from all subgraph queries, so that they stay valid eve


Configuration

📅 Schedule: Branch creation - At 12:00 AM through 04:59 AM and 10:00 PM through 11:59 PM, Monday through Friday ( * 0-4,22-23 * * 1-5 ), Only on Sunday and Saturday ( * * * * 0,6 ) (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

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

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


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

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

@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 7 times, most recently from fa53129 to cc932d2 Compare June 11, 2024 00:20
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 4 times, most recently from 9fb1f1b to 44dbce2 Compare June 19, 2024 01:28
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 7 times, most recently from 186adf5 to 663295f Compare June 27, 2024 01:24
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 4 times, most recently from e98b847 to 7c41f86 Compare July 3, 2024 04:23
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 5 times, most recently from efa9c9b to f3fed87 Compare July 17, 2024 08:59
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 3 times, most recently from 67af5a0 to f09ce08 Compare July 20, 2024 05:22
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 10 times, most recently from 70f7709 to e965402 Compare August 26, 2025 18:09
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 9 times, most recently from 185032f to 2e8fea1 Compare September 3, 2025 14:01
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 7 times, most recently from 00e02d8 to 62f996c Compare September 13, 2025 23:05
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from cd1d768 to 2607c67 Compare September 17, 2025 20:29
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 2607c67 to 166b7ce Compare September 23, 2025 16:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants