@apollo/server@4.6.0

Minor Changes

• #7465 1e808146a Thanks @trevor-scheer! - Introduce new opt-in configuration option to mitigate v4 status code regression

  Apollo Server v4 accidentally started responding to requests with an invalid variables object with a 200 status code, where v3 previously responded with a 400. In order to not break current behavior (potentially breaking users who have creatively worked around this issue) and offer a mitigation, we've added the following configuration option which we recommend for all users.

  new ApolloServer({
    // ...
    status400ForVariableCoercionErrors: true,
  });

  Specifically, this regression affects cases where input variable coercion fails. Variables of an incorrect type (i.e. String instead of Int) or unexpectedly null are examples that fail variable coercion. Additionally, missing or incorrect fields on input objects as well as custom scalars that throw during validation will also fail variable coercion. For more specifics on variable coercion, see the "Input Coercion" sections in the GraphQL spec.

  This will become the default behavior in Apollo Server v5 and the configuration option will be ignored / no longer needed.

Patch Changes

• #7454 f6e3ae021 Thanks @trevor-scheer! - Start building packages with TS 5.x, which should have no effect for users

• #7433 e0db95b96 Thanks @KGAdamCook! - Previously, when users provided their own documentStore, Apollo Server used a random prefix per schema in order to guarantee there was no shared state from one schema to the next. Now Apollo Server uses a hash of the schema, which enables the provided document store to be shared if you choose to do so.