fix(deps): update apollo graphql packages (major) by renovate[bot] · Pull Request #1523 · unraid/api

renovate · 2025-07-17T21:01:07Z

This PR contains the following updates:

Package	Change	Age	Confidence
@apollo/client (source)	`3.14.0` → `4.2.0`
@apollo/server (source)	`4.12.2` → `5.5.1`

Release Notes

apollographql/apollo-client (@apollo/client)

`v4.2.0`

Compare Source

Minor Changes

#13132 f3ce805 Thanks @phryneas! - Introduce "classic" and "modern" method and hook signatures.

Apollo Client 4.2 introduces two signature styles for methods and hooks. All signatures previously present are now "classic" signatures, and a new set of "modern" signatures are added alongside them.

Classic signatures are the default and are identical to the signatures before Apollo Client 4.2, preserving backward compatibility. Classic signatures still work with manually specified TypeScript generics (e.g., useSuspenseQuery<MyData>(...)). However, manually specifying generics has been discouraged for a long time—instead, we recommend using TypedDocumentNode to automatically infer types, which provides more accurate results without any manual annotations.

Modern signatures automatically incorporate your declared defaultOptions into return types, providing more accurate types. Modern signatures infer types from the document node and do not support manually passing generic type arguments; TypeScript will produce a type error if you attempt to do so.

Methods and hooks automatically switch to modern signatures the moment any non-optional property is declared in DeclareDefaultOptions. The switch happens across all methods and hooks globally:
```
// apollo.d.ts
import "@&#8203;apollo/client";
declare module "@&#8203;apollo/client" {
  namespace ApolloClient {
    namespace DeclareDefaultOptions {
      interface WatchQuery {
        errorPolicy: "all"; // non-optional → modern signatures activated automatically
      }
    }
  }
}
```
Users can also manually switch to modern signatures without declaring any defaultOptions, for example when wanting accurate type inference without relying on global defaultOptions:
```
// apollo.d.ts
import "@&#8203;apollo/client";
declare module "@&#8203;apollo/client" {
  export interface TypeOverrides {
    signatureStyle: "modern";
  }
}
```
Users can do a global DeclareDefaultOptions type augmentation and then manually switch back to "classic" for migration purposes:
```
// apollo.d.ts
import "@&#8203;apollo/client";
declare module "@&#8203;apollo/client" {
  export interface TypeOverrides {
    signatureStyle: "classic";
  }
}
```
Note that this is not recommended for long-term use. When combined with DeclareDefaultOptions, switching back to classic results in the same incorrect types as before Apollo Client 4.2—methods and hooks will not reflect the defaultOptions you've declared.
#13130 dd12231 Thanks @jerelmiller! - Improve the accuracy of client.query return type to better detect the current errorPolicy. The data property is no longer nullable when the errorPolicy is none. This makes it possible to remove the undefined checks or optional chaining in most cases.

#13210 1f9a428 Thanks @jerelmiller! - Add support for automatic event-based refetching, such as window focus.

The RefetchEventManager class handles automatic refetches in response to events. Apollo Client provides built-in sources for window focus and network reconnect as windowFocusSource and onlineSource.

Event refetching is fully opt-in. Create and pass a RefetchEventManager instance to the ApolloClient constructor to activate the event listeners.

import {
  ApolloClient,
  InMemoryCache,
  RefetchEventManager,
  windowFocusSource,
  onlineSource,
} from "@&#8203;apollo/client";

const client = new ApolloClient({
  link,
  cache: new InMemoryCache(),
  refetchEventManager: new RefetchEventManager({
    sources: {
      // Refetch when window is focused
      windowFocus: windowFocusSource,

      // Refetch when the user comes back online
      online: onlineSource,
    },
  }),
});

By default, all active queries refetch when the events fire. Queries can opt out per-event or disable all event refetches:

// Skip refetch on window focus for this query, but keep `online`
useQuery(QUERY, {
  refetchOn: { windowFocus: false },
});

// Disable all event-driven refetches for this query
useQuery(OTHER_QUERY, {
  refetchOn: false,
});

// Enable every event for this query, regardless of defaultOptions
useQuery(LIVE_DASHBOARD, {
  refetchOn: true,
});

// Dynamically enable or disable a refetch when the event fires
useQuery(LIVE_DASHBOARD, {
  refetchOn: ({ source, payload }) => {
    if (source === "windowFocus") {
      // payload is the data associated with the event
      return someCondition(payload);
    }

    return true;
  },
});

// Dynamically enable or disable a refetch for a specific event
useQuery(LIVE_DASHBOARD, {
  refetchOn: {
    windowFocus: ({ payload }) => {
      // payload is the data associated with the event
      return someCondition(payload);
    },
  },
});

To enable per-query opt-in rather than opt-out, set defaultOptions.watchQuery.refetchOn to false and enable it per-query instead.

const client = new ApolloClient({
  link,
  cache,
  refetchEventManager: new RefetchEventManager({
    sources: { windowFocus: windowFocusSource },
  }),
  defaultOptions: {
    watchQuery: { refetchOn: false },
  },
});

// Only this query refetches on window focus
useQuery(DASHBOARD_QUERY, { refetchOn: { windowFocus: true } });

When defaultOptions.watchQuery.refetchOn and per-query refetchOn options are provided, the objects are merged together.

Custom events

You can also add your own custom events that trigger refetches. Register your event name and payload type using TypeScript module augmentation, then provide a source function that returns an Observable. The source's emitted value becomes the event's payload.

import { Observable } from "@&#8203;apollo/client";
import { filter } from "rxjs";
import { AppState, AppStateStatus, Platform } from "react-native";

declare module "@&#8203;apollo/client" {
  interface RefetchEvents {
    reactNativeAppStatus: AppStateStatus;
  }
}

const refetchEventManager = new RefetchEventManager({
  sources: {
    reactNativeAppStatus: () => {
      return new Observable((observer) => {
        const subscription = AppState.addEventListener("change", (status) => {
          observer.next(status);
        });
        return () => subscription.remove();
      }).pipe(
        filter((status) => Platform.OS !== "web" && status === "active")
      );
    },
  },
});

// Disable per-query by setting the event to false
useQuery(QUERY, { refetchOn: { reactNativeAppStatus: false } });

Manually trigger an event refetch

Refetches can be triggered imperatively by calling emit with the event name and its payload (if any).

refetchEventManager.emit("reactNativeAppStatus", "active");

Sourceless events

A source that has no automatic detection logic but still wants imperative emit support can be declared as true. Type the event as void to omit the payload argument.

declare module "@&#8203;apollo/client" {
  interface RefetchEvents {
    userTriggered: void;
  }
}

const refetchEventManager = new RefetchEventManager({
  sources: { userTriggered: true },
});

refetchEventManager.emit("userTriggered");

Note: Calling emit on an event without a registered source will log a warning and result in a no-op.

Custom handlers

When an event fires, the default handler calls client.refetchQueries({ include: "active" }) filtered by each query's refetchOn setting. You can override the handler for an event to add your own custom filtering. For example, to refetch all queries, including standby queries, define a handler for the event:

const refetchEventManager = new RefetchEventManager({
  // ...
  handlers: {
    userTriggered: ({ client, source, payload, matchesRefetchOn }) => {
      return client.refetchQueries({
        include: "all",
        onQueryUpdated: (observableQuery) => {
          return matchesRefetchOn(observableQuery);
        },
      });
    },
  },
});

Handlers must return either a RefetchQueriesResult or void. Returning void skips refetching for the event.

#13232 f1b541f Thanks @jerelmiller! - Version bump to rc.
#13206 08fccab Thanks @jerelmiller! - Extend the defaultOptions type-safety work to client.mutate and useMutation.

The errorPolicy option now flows through to the result types for mutations in the same way it already does for queries:
- ApolloClient.MutateResult<TData, TErrorPolicy> maps errorPolicy to the concrete shape of data and error:
  - "none" → { data: TData; error?: never }
  - "all" → { data: TData | undefined; error?: ErrorLike }
  - "ignore" → { data: TData | undefined; error?: never }
- client.mutate and useMutation pick up the declared defaultOptions.mutate.errorPolicy and the explicit errorPolicy on each call to narrow return types accordingly.
- useMutation.Result.error is narrowed to undefined when errorPolicy is "ignore", since client.mutate never resolves with an error in that case.
DeclareDefaultOptions.Mutate already accepted errorPolicy; the new behavior is that once you declare it, hook and method return types reflect it:
```
// apollo.d.ts
import "@&#8203;apollo/client";

declare module "@&#8203;apollo/client" {
  namespace ApolloClient {
    namespace DeclareDefaultOptions {
      interface Mutate {
        errorPolicy: "all";
      }
    }
  }
}
```
```
const result = await client.mutate({ mutation: MUTATION });
result.data;
//     ^? TData | undefined
result.error;
//     ^? ErrorLike | undefined
```
Setting errorPolicy on an individual call overrides the default for that call's return type.

#13222 b93c172 Thanks @jerelmiller! - Extend the defaultOptions type-safety work to preloadQuery (returned from createQueryPreloader). Defaults declared in DeclareDefaultOptions.WatchQuery now work with preloadQuery to ensure the PreloadedQueryRef's data states are correctly set.

// apollo.d.ts
import "@&#8203;apollo/client";

declare module "@&#8203;apollo/client" {
  namespace ApolloClient {
    namespace DeclareDefaultOptions {
      interface WatchQuery {
        errorPolicy: "all";
      }
    }
  }
}

const preloadQuery = createQueryPreloader(client);
const queryRef = preloadQuery(QUERY);
//    ^? PreloadedQueryRef<TData, TVariables, "complete" | "streaming" | "empty">

#13132 f3ce805 Thanks @phryneas! - Synchronize method and hook return types with defaultOptions.

Prior to this change, the following code snippet would always apply:
```
declare const MY_QUERY: TypedDocumentNode<TData, TVariables>;
const result1 = useSuspenseQuery(MY_QUERY);
result1.data;
//      ^? TData
const result2 = useSuspenseQuery(MY_QUERY, { errorPolicy: "all" });
result2.data;
//      ^? TData | undefined
```
While these types are generally correct, if you were to set errorPolicy: 'all' as a default option, the type of result.data for the first query would remain TData instead of changing to TData | undefined to match the runtime behavior.

We are now enforcing that certain defaultOptions types need to be registered globally. This means that if you want to use errorPolicy: 'all' as a default option for a query, you will need to register its type like this:
```
// apollo.d.ts
import "@&#8203;apollo/client";

declare module "@&#8203;apollo/client" {
  namespace ApolloClient {
    namespace DeclareDefaultOptions {
      interface WatchQuery {
        // possible global-registered values:
        // * `errorPolicy`
        // * `returnPartialData`
        errorPolicy: "all";
      }
      interface Query {
        // possible global-registered values:
        // * `errorPolicy`
      }
      interface Mutate {
        // possible global-registered values:
        // * `errorPolicy`
      }
    }
  }
}
```
Once this type declaration is in place, the type of result.data in the above example will correctly be changed to TData | undefined, reflecting the possibility that if an error occurs, data might be undefined. Manually specifying useSuspenseQuery(MY_QUERY, { errorPolicy: "none" }); changes result.data to TData to reflect the local override.

This change means that you will need to declare your default options types in order to use defaultOptions with ApolloClient, otherwise you will see a TypeScript error.

Without the type declaration, the following (previously valid) code will now error:
```
new ApolloClient({
  link: ApolloLink.empty(),
  cache: new InMemoryCache(),
  defaultOptions: {
    watchQuery: {
      // results in a type error:
      // Type '"all"' is not assignable to type '"A default option for watchQuery.errorPolicy must be declared in ApolloClient.DeclareDefaultOptions before usage. See https://www.apollographql.com/docs/react/data/typescript#declaring-default-options-for-type-safety."'.
      errorPolicy: "all",
    },
  },
});
```
If you are creating multiple instances of Apollo Client with conflicting default options and you cannot register a single defaultOptions value as a result, you can relax the constraints by declaring those options as union types covering all values used by all clients. The properties can be required (to enforce them in defaultOptions) or optional (if some constructor calls won't pass a value):
```
// apollo.d.ts
import "@&#8203;apollo/client";

declare module "@&#8203;apollo/client" {
  export namespace ApolloClient {
    export namespace DeclareDefaultOptions {
      interface WatchQuery {
        errorPolicy?: "none" | "all" | "ignore";
        returnPartialData?: boolean;
      }
      interface Query {
        errorPolicy?: "none" | "all" | "ignore";
      }
      interface Mutate {
        errorPolicy?: "none" | "all" | "ignore";
      }
    }
  }
}
```
With this declaration, the ApolloClient constructor accepts any of those values in defaultOptions. The tradeoff is that hook and method return types become more generic. For example, calling useSuspenseQuery without an explicit errorPolicy will return a result typed as if all error policies are possible, since TypeScript can't know which specific value your instance uses at runtime.

Note that making a property optional (errorPolicy?:) is equivalent to adding the TypeScript default value ("none") to the union. So errorPolicy?: "all" | "ignore" has the same effect on return types as errorPolicy: "none" | "all" | "ignore", because TypeScript assumes the option could also be absent (i.e., "none").

You can also use a partial union that only lists the values you actually use. For example, if you only ever use "all" or "ignore", declare errorPolicy: "all" | "ignore" (required) to keep the union narrow and avoid unused values broadening your signatures unnecessarily.

Patch Changes

#13217 790f987 Thanks @jerelmiller! - Fix the deprecation for the classic signatures for function overloads that rely on type inference from a TypedDocumentNode. The deprecation now only applies to classic signatures that provide explicit type arguments to encourage the use of TypedDocumentNode.
#13166 0537d97 Thanks @jerelmiller! - Release changes in 4.1.5 and 4.1.6.
#13215 54c9eb7 Thanks @jerelmiller! - Ensure the options object for the useQuery, useSuspenseQuery, and useBackgroundQuery hooks provide proper IntelliSense suggestions.
#13229 9a7f65a Thanks @jerelmiller! - Fix refetchOn merging when defaultOptions.watchQuery.refetchOn is set to a non-object value (false, true, or a function) and the per-query refetchOn is an object. Previously the per-query object completely replaced the default so unspecified events fell back to "enabled" regardless of the default.

The defaultOptions value now applies to any event the per-query object does not explicitly configure:
- false - unspecified events stay disabled
- true - unspecified events refetch
- Callback function - the function is called for unspecified events to determine whether to refetch
```
const client = new ApolloClient({
  // ...
  defaultOptions: {
    watchQuery: {
      refetchOn: false,
    },
  },
});

// Only `windowFocus` refetches. Other events stay disabled per the default.
useQuery(QUERY, { refetchOn: { windowFocus: true } });
```
#13230 b25b659 Thanks @jerelmiller! - Add the ability to override the default event handler on RefetchEventManager. The default handler runs when no per-source handler is configured for an event. Provide a custom handler via the defaultHandler constructor option or the setDefaultEventHandler instance method.
```
new RefetchEventManager({
  defaultHandler: ({ client, matchesRefetchOn }) => {
    return client.refetchQueries({
      include: "all",
      onQueryUpdated: matchesRefetchOn,
    });
  },
});
```

`v4.1.9`

Compare Source

Patch Changes

#13203 099954b Thanks @copilot-swe-agent! - Remove the workspaces field from the published package.json in dist to avoid Yarn v1 warnings about workspaces requiring private packages.

`v4.1.8`

Compare Source

Patch Changes

#13202 8a51ea6 Thanks @phryneas! - Ship agent skill for usage with @tanstack/intent — the skill is now bundled in the npm package under skills/apollo-client/ and discoverable by intent list.
For more context, see the TanStack Intent QuickStart.

Patch Changes

#12950 5b4f36a Thanks @jerelmiller! - Don't send operationType in the payload sent by GraphQLWsLink.

`v4.0.6`

Compare Source

Patch Changes

#12937 3b0d89b Thanks @phryneas! - Fix a problem with fetchMore where the loading state wouldn't reset if the result wouldn't result in a data update.

`v4.0.5`

Compare Source

Patch Changes

#12920 e2fc385 Thanks @phryneas! - Fix an invariance type error in the MockedResponse type.

`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 "@&#8203;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

#12887 6f6ca47 Thanks @phryneas! - Fix accidental deep re-export from /react out of /react/internals
#12890 019b422 Thanks @jerelmiller! - Ensure the variables option for useMutation provides proper IntelliSense suggestions.

`v4.0.2`

Compare Source

Patch Changes

#12880 56fac52 Thanks @phryneas! - restore getMemoryInternals access in dev builds

`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

`v3.14.1`

Compare Source

Patch Changes

#13168 6b84ec0 Thanks @jerelmiller! - Fix issue where muting a deprecation from one entrypoint would not mute the warning when checked in a different entrypoint. This caused some rogue deprecation warnings to appear in the console even though the warnings should have been muted.
#12970 f91fab5 Thanks @acemir! - Add a deprecation message for the variableMatcher option in MockLink.
#13168 6b84ec0 Thanks @jerelmiller! - Ensure deprecation warnings are properly silenced in React hooks when globally disabled.

apollographql/apollo-server (@apollo/server)

`v5.5.1`

Compare Source

Patch Changes

#8201 3f46c51 Thanks @mhassan1! - Replace dependency uuid with calls to crypto.randomUUID.

`v5.5.0`

Compare Source

Minor Changes

#8191 ada1200 Thanks @glasser! - ⚠️ SECURITY @apollo/server/standalone:

Apollo Server now rejects GraphQL GET requests which contain a Content-Type header other than application/json (with optional parameters such as ; charset=utf-8). Any other value is now rejected with a 415 status code.

(GraphQL GET requests without a Content-Type header are still allowed, though they do still need to contain a non-empty X-Apollo-Operation-Name or Apollo-Require-Preflight header to be processed if the default CSRF prevention feature is enabled.)

This improvement makes Apollo Server's CSRF more resistant to browsers which implement CORS in non-spec-compliant ways. Apollo is aware of one browser which as of March 2026 has a bug which allows an attacker to circumvent Apollo Server's CSRF prevention feature to carry out read-only XS-Search-style CSRF attacks. The browser vendor is in the process of patching this vulnerability; upgrading Apollo Server to v5.5.0 mitigates this vulnerability.

If your server uses cookies (or HTTP Basic Auth) for authentication, Apollo encourages you to upgrade to v5.5.0.

This is technically a backwards-incompatible change. Apollo is not aware of any GraphQL clients which provide non-empty Content-Type headers with GET requests with types other than application/json. If your use case requires such requests, please file an issue and we may add more configurability in a follow-up release.

See advisory GHSA-9q82-xgwf-vj6h for more details.

`v5.4.0`

Compare Source

Minor Changes

d25a5bd Thanks @phryneas! - ⚠️ SECURITY @apollo/server/standalone:

The default configuration of startStandaloneServer was vulnerable to denial of service (DoS) attacks through specially crafted request bodies with exotic character set encodings.

In accordance with RFC 7159, we now only accept request bodies encoded in UTF-8, UTF-16 (LE or BE), or UTF-32 (LE or BE).
Any other character set will be rejected with a 415 Unsupported Media Type error.
Note that the more recent JSON RFC, RFC 8259, is more strict and will only allow UTF-8.
Since this is a minor release, we have chosen to remain compatible with the more permissive RFC 7159 for now.
In a future major release, we may tighten this restriction further to only allow UTF-8.

If you were not using startStandaloneServer, you were not affected by this vulnerability.

Generally, please note that we provide startStandaloneServer as a convenience tool for quickly getting started with Apollo Server.
For production deployments, we recommend using Apollo Server with a more fully-featured web server framework such as Express, Koa, or Fastify, where you have more control over security-related configuration options.

`v5.3.0`

Compare Source

Minor Changes

#8062 8e54e58 Thanks @cristunaranjo! - Allow configuration of graphql execution options (maxCoercionErrors)

const server = new ApolloServer({
  typeDefs,
  resolvers,
  executionOptions: {
    maxCoercionErrors: 50,
  },
});

#8014 26320bc Thanks @mo4islona! - Expose graphql validation options.

const server = new ApolloServer({
  typeDefs,
  resolvers,
  validationOptions: {
    maxErrors: 10,
  },
});

`v5.2.0`

Compare Source

Minor Changes

#8161 51acbeb Thanks @jerelmiller! - Fix an issue where some bundlers would fail to build because of the dynamic import for the optional peer dependency on @yaacovcr/transform introduced in @apollo/server 5.1.0. To provide support for the legacy incremental format, you must now provide the legacyExperimentalExecuteIncrementally option to the ApolloServer constructor.
```
import { legacyExecuteIncrementally } from '@&#8203;yaacovcr/transform';

const server = new ApolloServer({
  // ...
  legacyExperimentalExecuteIncrementally: legacyExecuteIncrementally,
});
```
If the legacyExperimentalExecuteIncrementally option is not provided and the client sends an Accept header with a value of multipart/mixed; deferSpec=20220824, an error is returned by the server.

`v5.1.0`

Compare Source

Minor Changes

#8148 80a1a1a Thanks @jerelmiller! - Apollo Server now supports the incremental delivery protocol (@defer and @stream) that ships with graphql@17.0.0-alpha.9. To use the current protocol, clients must send the Accept header with a value of multipart/mixed; incrementalSpec=v0.2.

Upgrading to 5.1 will depend on what version of graphql you have installed and whether you already support the incremental delivery protocol.

`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]:
- @apollo/server-gateway-interface@2.0.0

`v4.13.0`

Compare Source

Minor Changes

#8180 e9d49d1 Thanks @github-actions! - ⚠️ SECURITY @apollo/server/standalone:

The default configuration of startStandaloneServer was vulnerable to denial of service (DoS) attacks through specially crafted request bodies with exotic character set encodings.

In accordance with RFC 7159, we now only accept request bodies encoded in UTF-8, UTF-16 (LE or BE), or UTF-32 (LE or BE).
Any other character set will be rejected with a 415 Unsupported Media Type error.
Additionally, upstream libraries used by this version of Apollo Server may not support all of these encodings, so some requests may still fail even if they pass this check.

If you were not using startStandaloneServer, you were not affected by this vulnerability.

Generally, please note that we provide startStandaloneServer as a convenience tool for quickly getting started with Apollo Server.
For production deployments, we recommend using Apollo Server with a more fully-featured web server framework such as Express, Koa, or Fastify, where you have more control over security-related configuration options.

Also please note that Apollo Server 4.x is considered EOL as of January 26, 2026, and Apollo no longer commits to providing support or updates for it. Please prioritize migrating to Apollo Server 5.x for continued support and updates.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

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

♻ Rebasing: Whenever PR becomes conflicted, 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.

coderabbitai · 2025-07-17T21:01:13Z

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

🔍 Trigger a full review

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

renovate Bot requested review from elibosley, mdatelle, pujitm and zackspear as code owners July 17, 2025 21:01

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 5 times, most recently from e417abc to 50fbac9 Compare July 25, 2025 19:14

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch from 50fbac9 to 623752b Compare July 28, 2025 15:13

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 4 times, most recently from 5073e7f to 62d3829 Compare August 13, 2025 14:19

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from e5cff25 to 0a58a36 Compare August 21, 2025 23:33

renovate Bot changed the title ~~fix(deps): update dependency @apollo/server to v5~~ fix(deps): update apollo graphql packages (major) Aug 21, 2025

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 5 times, most recently from ad96144 to 3264554 Compare August 31, 2025 10:15

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 3 times, most recently from 07199b1 to cfa6bb4 Compare September 8, 2025 15:09

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 4 times, most recently from c8225bc to 0b32917 Compare September 14, 2025 19:22

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 3 times, most recently from 0b9f157 to cd4cdcf Compare October 2, 2025 15:10

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from dc8427f to cb159de Compare October 13, 2025 21:02

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from 7ff4772 to dd9a88b Compare October 27, 2025 18:12

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from 183427c to 4c76cba Compare October 31, 2025 19:06

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from 9f798ce to 88d3436 Compare November 10, 2025 15:53

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from 3bcebc2 to 66bb0ed Compare November 21, 2025 23:58

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from 6fedea6 to 4061d0f Compare December 10, 2025 09:16

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 3 times, most recently from 9dd5a3c to 8d80431 Compare December 16, 2025 20:52

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch from 8d80431 to 85b947d Compare December 31, 2025 14:40

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 3 times, most recently from 5e0f4fb to 81b2b44 Compare January 13, 2026 21:55

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 5 times, most recently from d0e6007 to d55c142 Compare January 21, 2026 14:40

renovate Bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from b24c00d to 374d064 Compare January 28, 2026 21:02

fix(deps): update apollo graphql packages

7556589

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(deps): update apollo graphql packages (major)#1523

fix(deps): update apollo graphql packages (major)#1523
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/major-apollo-graphql-packages

renovate Bot commented Jul 17, 2025 •

edited

Loading

Uh oh!

coderabbitai Bot commented Jul 17, 2025 •

edited

Loading

Review skipped

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Release Notes

Minor Changes

Custom events

Manually trigger an event refetch

Sourceless events

Custom handlers

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Minor Changes

Minor Changes

Minor Changes

Minor Changes

Minor Changes

BREAKING CHANGES

Patch Changes

Minor Changes

Configuration

Uh oh!

coderabbitai Bot commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

renovate Bot commented Jul 17, 2025 •

edited

Loading

coderabbitai Bot commented Jul 17, 2025 •

edited

Loading