Skip to content

fix(deps): update apollo graphql packages #289

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix(deps): update apollo graphql packages #289

wants to merge 1 commit into from

Conversation

@svc-secops
Copy link
Contributor

@svc-secops svc-secops commented May 3, 2025 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence Type Update
@apollo/client (source) 3.12.3 -> 3.14.0 age adoption passing confidence dependencies minor
@apollo/client-devtools-vscode 4.20.1 -> 4.21.10 age adoption passing confidence dependencies minor
@apollo/subgraph (source) 2.9.3 -> 2.11.3 age adoption passing confidence dependencies minor
ghcr.io/apollographql/router v2.2.0 -> v2.8.0 age adoption passing confidence final minor

Release Notes

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

v3.14.0

Compare Source

Minor Changes
Patch Changes

v3.13.9

Compare Source

Patch Changes
  • #​12804 32c9aa9 Thanks @​phryneas! - Fix a possible race condition on queries that were reobserved before they were subscribed to the first time.

v3.13.8

Compare Source

Patch Changes

v3.13.7

Compare Source

Patch Changes

v3.13.6

Compare Source

Patch Changes

v3.13.5

Compare Source

Patch Changes
  • #​12461 12c8d06 Thanks @​jerelmiller! - Fix an issue where a cache-first query would return the result for previous variables when a cache update is issued after simultaneously changing variables and skipping the query.

v3.13.4

Compare Source

Patch Changes

v3.13.3

Compare Source

Patch Changes

  • #​12362 f6d387c Thanks @​jerelmiller! - Fixes an issue where calling observableQuery.getCurrentResult() when the errorPolicy was set to all would return the networkStatus as NetworkStatus.ready when there were errors returned in the result. This has been corrected to report NetworkStatus.error.

    This bug also affected the useQuery and useLazyQuery hooks and may affect you if you check for networkStatus in your component.

v3.13.2

Compare Source

Patch Changes

  • #​12409 6aa2f3e Thanks @​phryneas! - To mitigate problems when Apollo Client ends up more than once in the bundle, some unique symbols were converted into Symbol.for calls.

  • #​12392 644bb26 Thanks @​Joja81! - Fixes an issue where the DeepOmit type would turn optional properties into required properties. This should only affect you if you were using the omitDeep or stripTypename utilities exported by Apollo Client.

  • #​12404 4332b88 Thanks @​jerelmiller! - Show NaN rather than converting to null in debug messages from MockLink for unmatched variables values.

v3.13.1

Compare Source

Patch Changes

v3.13.0

Compare Source

Minor Changes

  • #​12066 c01da5d Thanks @​jerelmiller! - Adds a new useSuspenseFragment hook.

    useSuspenseFragment suspends until data is complete. It is a drop-in replacement for useFragment when you prefer to use Suspense to control the loading state of a fragment. See the documentation for more details.

  • #​12174 ba5cc33 Thanks @​jerelmiller! - Ensure errors thrown in the onCompleted callback from useMutation don't call onError.

  • #​12340 716d02e Thanks @​phryneas! - Deprecate the onCompleted and onError callbacks of useQuery and useLazyQuery.
    For more context, please see the related issue on GitHub.

  • #​12276 670f112 Thanks @​Cellule! - Provide a more type-safe option for the previous data value passed to observableQuery.updateQuery. Using it could result in crashes at runtime as this callback could be called with partial data even though its type reported the value as a complete result.

    The updateQuery callback function is now called with a new type-safe previousData property and a new complete property in the 2nd argument that determines whether previousData is a complete or partial result.

    As a result of this change, it is recommended to use the previousData property passed to the 2nd argument of the callback rather than using the previous data value from the first argument since that value is not type-safe. The first argument is now deprecated and will be removed in a future version of Apollo Client.

    observableQuery.updateQuery(
  (unsafePreviousData, { previousData, complete }) => {
    previousData;
    // ^? TData | DeepPartial<TData> | undefined

    if (complete) {
      previousData;
      // ^? TData
    } else {
      previousData;
      // ^? DeepPartial<TData> | undefined
    }
  }
);

  • #​12174 ba5cc33 Thanks @​jerelmiller! - Reject the mutation promise if errors are thrown in the onCompleted callback of useMutation.

Patch Changes

  • #​12276 670f112 Thanks @​Cellule! - Fix the return type of the updateQuery function to allow for undefined. updateQuery had the ability to bail out of the update by returning a falsey value, but the return type enforced a query value.

    observableQuery.updateQuery(
  (unsafePreviousData, { previousData, complete }) => {
    if (!complete) {
      // Bail out of the update by returning early
      return;
    }

    // ...
  }
);

  • #​12296 2422df2 Thanks @​Cellule! - Deprecate option ignoreResults in useMutation.
    Once this option is removed, existing code still using it might see increase in re-renders.
    If you don't want to synchronize your component state with the mutation, please use useApolloClient to get your ApolloClient instance and call client.mutate directly.

  • #​12338 67c16c9 Thanks @​phryneas! - In case of a multipart response (e.g. with @defer), query deduplication will
    now keep going until the final chunk has been received.

  • #​12276 670f112 Thanks @​Cellule! - Fix the type of the variables property passed as the 2nd argument to the subscribeToMore callback. This was previously reported as the variables type for the subscription itself, but is now properly typed as the query variables.

v3.12.11

Compare Source

Patch Changes

  • #​12351 3da908b Thanks @​jerelmiller! - Fixes an issue where the wrong networkStatus and loading value was emitted from observableQuery when calling fetchMore with a no-cache fetch policy. The networkStatus now properly reports as ready and loading as false after the result is returned.

  • #​12354 a24ef94 Thanks @​phryneas! - Fix missing main.d.cts file

v3.12.10

Compare Source

Patch Changes

v3.12.9

Compare Source

Patch Changes

v3.12.8

Compare Source

Patch Changes

v3.12.7

Compare Source

Patch Changes

v3.12.6

Compare Source

Patch Changes

v3.12.5

Compare Source

Patch Changes

  • #​12252 cb9cd4e Thanks @​jerelmiller! - Changes the default behavior of the MaybeMasked type to preserve types unless otherwise specified. This change makes it easier to upgrade from older versions of the client where types could have unexpectedly changed in the application due to the default of trying to unwrap types into unmasked types. This change also fixes the compilation performance regression experienced when simply upgrading the client since types are now preserved by default.

    A new mode option has now been introduced to allow for the old behavior. See the next section on migrating if you wish to maintain the old default behavior after upgrading to this version.

Migrating from <= v3.12.4

If you've adopted data masking and have opted in to using masked types by setting the enabled property to true, you can remove this configuration entirely:

-declare module "@&#8203;apollo/client" {
-  interface DataMasking {
-    mode: "unmask"
-  }
-}

If you prefer to specify the behavior explicitly, change the property from enabled: true, to mode: "preserveTypes":

declare module "@&#8203;apollo/client" {
  interface DataMasking {
-    enabled: true
+    mode: "preserveTypes"
  }
}

If you rely on the default behavior in 3.12.4 or below and would like to continue to use unmasked types by default, set the mode to unmask:

declare module "@&#8203;apollo/client" {
  interface DataMasking {
    mode: "unmask";
  }
}

v3.12.4

Compare Source

Patch Changes
  • #​12236 4334d30 Thanks @​charpeni! - Fix an issue with refetchQueries where comparing DocumentNodes internally by references could lead to an unknown query, even though the DocumentNode was indeed an active query—with a different reference.
apollographql/apollo-client-devtools (@​apollo/client-devtools-vscode)

v4.21.10

Compare Source

Patch Changes

v4.21.9

Compare Source

Patch Changes

v4.21.8

Compare Source

Patch Changes

v4.21.7

Compare Source

Patch Changes

v4.21.6

Compare Source

Patch Changes

v4.21.5

Compare Source

v4.21.4

Compare Source

Patch Changes

v4.21.3

Compare Source

Patch Changes

v4.21.2

Compare Source

Patch Changes
  • #​1713 0302538 Thanks @​braineo! - fix calling client.stop twice causing app crashing by checking if handler exist before sending tab command

v4.21.1

Compare Source

Patch Changes

v4.21.0

Compare Source

Minor Changes

v4.20.2

Compare Source

Patch Changes
apollographql/federation (@​apollo/subgraph)

v2.11.3

Compare Source

Patch Changes

v2.11.2

Compare Source

Patch Changes

v2.11.1

Compare Source

Patch Changes

v2.11.0

Compare Source

Minor Changes
  • Adds connect spec v0.2, available for use with Apollo Router 2.3.0 or greater. (#​3262)
Patch Changes

v2.10.2

Compare Source

Patch Changes

v2.10.1

Compare Source

Patch Changes

v2.10.0

Compare Source

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

v2.8.0

Compare Source

🚀 Features
Response caching

Available on all GraphOS plans including Free, Developer, Standard and Enterprise.

Response caching enables the router to cache GraphQL subgraph origin responses using Redis, delivering performance improvements by reducing subgraph load and query latency. Unlike traditional HTTP caching or client-side caching, response caching works at the GraphQL entity level—caching reusable portions of query responses that can be shared across different operations and users.

Response caching caches two types of data:

  • Root query fields: Responses for root field fetches
  • Entity representations: Individual entities, offering reuse across queries

Benefits include:

  • Active cache invalidation: Target specific cached data for immediate removal using cache tags
  • Cache debugger: Debugging in Apollo Sandbox shows cache status, TTLs, and cache tags during development
  • GraphQL-aware: Understands GraphQL operations to improve partial cache hit rates while respecting data visibility and authorization
  • Entity-level granularity: Caches at the entity level rather than entire responses
  • Flexible TTL control: Data cached using HTTP Cache-Control headers from subgraph origins

Response caching solves traditional GraphQL caching challenges including mixed TTL requirements across a single response, personalized versus public data mixing, and high data duplication.

Configure response caching using the preview_response_cache configuration option with Redis as the cache backend. For complete setup instructions and advanced configuration, see the Response Caching documentation.

Migration from entity caching: For existing entity caching users, migration is as simple as renaming configuration options. For migration details see the Response Caching FAQ.

Support per-stage coprocessor URLs (PR #​8384)

You can now configure different coprocessor URLs for each stage of request/response processing (router, supergraph, execution, subgraph). Each stage can specify its own url field that overrides the global default URL.

Changes:

  • Add optional url field to all stage configuration structs
  • Update all stage as_service methods to accept and resolve URLs
  • Add tests for URL validation and per-stage configuration

This change maintains full backward compatibility—existing configurations with a single global URL continue to work unchanged.

By @​cgati in https://github.com/apollographql/router/pull/8384

Add automatic unit conversion for duration instruments with non-second units

The router now automatically converts duration measurements to match the configured unit for telemetry instruments.
Previously, duration instruments always recorded values in seconds regardless of the configured unit field.
When you specify units like "ms" (milliseconds), "us" (microseconds), or "ns" (nanoseconds),
the router automatically converts the measured duration to the appropriate scale.

Supported units:

  • "s" - seconds (default)
  • "ms" - milliseconds
  • "us" - microseconds
  • "ns" - nanoseconds

[!NOTE]
Use this feature only when you need to integrate with an observability platform that doesn't properly translate from source time units to target time units (for example, seconds to milliseconds). In all other cases, follow the OTLP convention that you "SHOULD" use seconds as the unit.

Example:

telemetry:
  instrumentation:
    instruments:
      subgraph:
        acme.request.duration:
          value: duration
          type: histogram
          unit: ms # Values are now automatically converted to milliseconds
          description: "Metric to get the request duration in milliseconds"

By @​theJC in https://github.com/apollographql/router/pull/8415

Add response reformatting and result coercion errors (PR #​8441)

All subgraph responses are checked and corrected to ensure alignment with the schema and query. When a misaligned value is returned, it's nullified. When enabled, errors for this nullification are now included in the errors array in the response.

Enable this feature in your router configuration:

supergraph:
  enable_result_coercion_errors: true

When enabled, the router generates validation errors with the code RESPONSE_VALIDATION_FAILED for any values that don't match the expected GraphQL type. These errors include the specific path and reason for the validation failure, helping you identify data inconsistencies between your subgraphs and schema.

While this feature improves GraphQL correctness, clients may encounter errors in responses where they previously did not, which may require consideration based on your specific usage patterns.

By @​TylerBloom in https://github.com/apollographql/router/pull/8441

Add router overhead metric (PR #​8455)

The apollo.router.overhead histogram provides a direct measurement of router processing overhead. This metric tracks the time the router spends on tasks other than waiting for downstream HTTP requests—including GraphQL parsing, validation, query planning, response composition, and plugin execution.

The overhead calculation excludes time spent waiting for downstream HTTP services (subgraphs and connectors), giving you visibility into the router's actual processing time versus downstream latency. This metric helps identify when the router itself is a bottleneck versus when delays are caused by downstream services.

Note: Coprocessor request time is currently included in the overhead calculation. In a future release, coprocessor time may be excluded similar to subgraphs and connectors.

telemetry:
  instrumentation:
    instruments:
      router:
        apollo.router.overhead: true

[!NOTE]
Note that the use of this metric is nuanced, and there is risk of misinterpretation. See the full docs for this metric to help understand how it can be used.

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

Include invalid Trace ID values in error logs (PR #​8149)

Error messages for malformed Trace IDs now include the invalid value to help with debugging. Previously, when the router received an unparseable Trace ID in incoming requests, error logs only indicated that the Trace ID was invalid without showing the actual value.

Trace IDs can be unparseable due to invalid hexadecimal characters, incorrect length, or non-standard formats. Including the invalid value in error logs makes it easier to diagnose and resolve tracing configuration issues.

By @​juancarlosjr97 in https://github.com/apollographql/router/pull/8149

Add ability to rename metrics (PR #​8424)

The router can now rename instruments via OpenTelemetry views. Details on how to use this feature can be found in the docs.

Benefits:

  • Cost optimization: Some observability platforms only allow tag indexing controls on a per-metric name basis. Using OTLP semantic naming conventions and having the same metric name emitted by different services can prevent effective use of these controls.
  • Convention alignment: Many customers have specific metric naming conventions across their organization—this feature allows them to align with those conventions.

By @​theJC in https://github.com/apollographql/router/pull/8412

🐛 Fixes
Reload telemetry only when configuration changes (PR #​8328)

Previously, schema or config reloads would always reload telemetry, dropping existing exporters and creating new ones.

Telemetry exporters are now only recreated when relevant configuration has changed.

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

Replace Redis connections metric with clients metric (PR #​8161)

The apollo.router.cache.redis.connections metric has been removed and replaced with the apollo.router.cache.redis.clients metric.

The connections metric was implemented with an up-down counter that would sometimes not be collected properly (it could go negative). The name connections was also inaccurate since Redis clients each make multiple connections, one to each node in the Redis pool (if in clustered mode).

The new clients metric counts the number of clients across the router via an AtomicU64 and surfaces that value in a gauge.

[!NOTE]
The old metric included a kind attribute to reflect the number of clients in each pool (for example, entity caching, query planning). The new metric doesn't include this attribute; the purpose of the metric is to ensure the number of clients isn't growing unbounded (#​7319).

By @​carodewig in https://github.com/apollographql/router/pull/8161

Prevent entity caching of expired data based on Age header (PR #​8456)

When the Age header is higher than the max-age directive in Cache-Control, the router no longer caches the data because it's already expired.

For example, with these headers:

Cache-Control: max-age=5
Age: 90

The data won't be cached since Age (90) exceeds max-age (5).

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

Reduce config and schema reload log noise (PR #​8336)

File watch events during an existing hot reload no longer spam the logs. Hot reload continues as usual after the existing reload finishes.

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

Prevent query planning errors for @shareable mutation fields (PR #​8352)

Query planning a mutation operation that executes a @shareable mutation field at the top level may unexpectedly error when attempting to generate a plan where that mutation field is called more than once across multiple subgraphs. Query planning now avoids generating such plans.

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

Prevent UpDownCounter drift using RAII guards (PR #​8379)

UpDownCounters now use RAII guards instead of manual incrementing and decrementing, ensuring they're always decremented when dropped.

This fix resolves drift in apollo.router.opened.subscriptions that occurred due to manual incrementing and decrementing.

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

Reduce Rhai short circuit response log noise (PR #​8364)

Rhai scripts that short-circuit the pipeline by throwing now only log an error if a response body isn't present.

For example the following will NOT log:

    throw #{
        status: 403,
        body: #{
            errors: [#{
                message: "Custom error with body",
                extensions: #{
                    code: "FORBIDDEN"
                }
            }]
        }
    };

For example the following WILL log:

throw "An error occurred without a body";

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

Prevent query planning error where @requires subgraph jump fetches @key from wrong subgraph (PR #​8016)

During query planning, a subgraph jump added due to a @requires field may sometimes try to collect the necessary @key fields from an upstream subgraph fetch as an optimization, but it wasn't properly checking whether that subgraph had those fields. This is now fixed and resolves query planning errors with messages like "Cannot add selection of field T.id to selection set of parent type T".

By @​sachindshinde in [https://github.com/a

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - "after 8am and before 4pm on tuesday" in timezone America/Los_Angeles.

🚦 Automerge: Enabled.

♻ 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.

This PR has been generated by Renovate Bot.

@changeset-bot
Copy link

changeset-bot bot commented May 3, 2025 •
edited
Loading

⚠️ No Changeset found

Latest commit: 85da1a4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@github-actions
Copy link
Contributor

github-actions bot commented May 3, 2025 •
edited
Loading

You can download the latest build of the extension for this PR here:
vscode-apollo-0.0.0-build-1762021152.pr-289.commit-718dfb3.zip.

To install the extension, download the file, unzip it and install it in VS Code by selecting "Install from VSIX..." in the Extensions view.

Alternatively, run

code --install-extension vscode-apollo-0.0.0-build-1762021152.pr-289.commit-718dfb3.vsix --force

from the command line.

For older builds, please see the edit history of this comment.

@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch from e2af702 to 808ade3 Compare May 8, 2025 13:46
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch from 808ade3 to 8496bf2 Compare June 7, 2025 11:05
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch 2 times, most recently from 4110dca to 7398af0 Compare June 29, 2025 11:58
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch from 7398af0 to 274ceb9 Compare July 16, 2025 11:34
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch 2 times, most recently from 1df153b to 5727d61 Compare August 1, 2025 14:57
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch from 5727d61 to 8ca14f6 Compare August 12, 2025 15:33
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch 3 times, most recently from ce1430e to f52debb Compare August 28, 2025 11:27
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch 2 times, most recently from 2033424 to d45a5e8 Compare September 6, 2025 11:26
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch 3 times, most recently from b0f976f to b5c1a37 Compare September 16, 2025 12:30
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch 3 times, most recently from 0274d81 to b75a9a0 Compare September 24, 2025 12:45
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch 3 times, most recently from 04e4aea to 1b4f1aa Compare October 4, 2025 13:42
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch 2 times, most recently from 19bdd1c to 50fe276 Compare October 14, 2025 12:16
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch from 50fe276 to 9989a69 Compare October 29, 2025 13:57
@svc-secops svc-secops force-pushed the renovate/apollo-graphql-packages branch from 9989a69 to 85da1a4 Compare November 1, 2025 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

🎄 dependencies

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@svc-secops