Skip to content

chore(deps): update apollo graphql packages (major) #13

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

chore(deps): update apollo graphql packages (major) #13

wants to merge 1 commit into from

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Oct 20, 2021 •
edited
Loading

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@apollo/gateway (source) 0.23.0 -> 2.7.2 age adoption passing confidence
apollo-server (source) 2.21.0 -> 3.13.0 age adoption passing confidence

Release Notes

apollographql/federation (@​apollo/gateway)

v2.7.2

Compare Source

Patch Changes

v2.7.1

Compare Source

Patch Changes

v2.7.0

Compare Source

Minor Changes

  • Implement progressive @override functionality (#​2911)

    The progressive @override feature brings a new argument to the @override directive: label: String. When a label is added to an @override application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only.

    Out-of-the-box, the router will support a percentage-based use case for progressive @override. For example:

    type Query {
  hello: String @​override(from: "original", label: "percent(5)")
}

    The above example will override the root hello field from the "original" subgraph 5% of the time.

    More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service).

Patch Changes

v2.6.3

Compare Source

Patch Changes

v2.6.2

Compare Source

Patch Changes

v2.6.1

Compare Source

Patch Changes

v2.6.0

Compare Source

Minor Changes

  • Add more information to OpenTelemetry spans. (#​2700)

    Rename operationName to graphql.operation.name and add a
    graphql.operation.type attribute, in conformance with the OpenTelemetry
    Semantic Conventions for GraphQL. The operationName attribute is now
    deprecated, but it is still emitted alongside graphql.operation.name.

    Add a graphql.document span attribute to the gateway.request span,
    containing the entire GraphQL source sent in the request. This feature
    is disable by default.

    When one or more GraphQL or internal errors occur, report them in the
    OpenTelemetry span in which they took place, as an exception event. This
    feature is disabled by default.

    To enable the graphql.document span attribute and the exception event
    reporting, add the following entries to your ApolloGateway instance
    configuration:

    const gateway = new ApolloGateway({
  // ...
  telemetry: {
    // Set to `true` to include the `graphql.document` attribute
    includeDocument: true,
    // Set to `true` to report all exception events, or set to a number
    // to report at most that number of exception events per span
    reportExceptions: true,
    // or: reportExceptions: 1
  },
});

  • Update license field in package.json to use Elastic-2.0 SPDX identifier (#​2741)

  • Introduce the new @policy scope for composition (#​2818)

    Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @policy directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

    Users may now compose @policy applications from their subgraphs into a supergraph.

    The directive is defined as follows:

    scalar federation__Policy

directive @​policy(policies: [[federation__Policy!]!]!) on
  | FIELD_DEFINITION
  | OBJECT
  | INTERFACE
  | SCALAR
  | ENUM

    The Policy scalar is effectively a String, similar to the FieldSet type.

    In order to compose your @policy usages, you must update your subgraph's federation spec version to v2.6 and add the @policy import to your existing imports like so:

    @​link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@​policy"])

  • Add graphql.operation.name attribute on gateway.plan span (#​2807)

Patch Changes

v2.5.7

Compare Source

Patch Changes

v2.5.6

Compare Source

Patch Changes

v2.5.5

Compare Source

Patch Changes

  • Fix specific case for requesting __typename on interface entity type (#​2775)

    In certain cases, when resolving a __typename on an interface entity (due to it actual being requested in the operation), that fetch group could previously be trimmed / treated as useless. At a glance, it appears to be a redundant step, i.e.:

    { ... on Product { __typename id }} => { ... on Product { __typename} }

    It's actually necessary to preserve this in the case that we're coming from an interface object to an (entity) interface so that we can resolve the concrete __typename correctly.

  • Don't preserve useless fetches which downgrade __typename from a concrete type back to its interface type. (#​2778)

    In certain cases, the query planner was preserving some fetches which were "useless" that would rewrite __typename from its already-resolved concrete type back to its interface type. This could result in (at least) requested fields being "filtered" from the final result due to the interface's __typename in the data where the concrete type's __typename was expected.

    Specifically, the solution was compute the path between newly created groups and their parents when we know that it's trivial ([]). Further along in the planning process, this allows to actually remove the known-useless group.

  • Propagate type information when renaming entity fields (#​2776)

    Aliased entity fields might have been incorrectly overwritten if multiple fields/aliases shared the same name. Query planner automatically renames conflicting fields to ensure we can always generate a valid GraphQL query. The underlying issue was that this key rewriting logic was assuming the same type of an object. In case of entity queries asking for those aliased fields, we ended up always attempting to apply field renaming logic regardless, whether or not a given entity was of the correct type. This fix ensures that the query planner logic correctly accounts for the object type when applying field renaming logic.

  • Updated dependencies [66d7e4ce, a37bbbf6]:

v2.5.4

Compare Source

Patch Changes

  • Adds header to change the format of exposed query plans, and allows formatting it as json. (#​2724)

    When the gateway is configured to allow it, adding the Apollo-Query-Plan-Experimental header to a request already allowed a "prettified" text version of the query plan used for the query is returned in the response extension. This changes adds support for a new (optional) accompanying header, Apollo-Query-Plan-Experimental-Format, which can be set to the value "internal" to have the query plan returned as a json object (that correspond to the internal representation of that query plan) instead of the text version otherwise sent. Note that if that new header is not provided, then the query plan continues to be send in the previous prettified text version.

  • Fix some potentially incorrect query plans with @requires when some dependencies are involved. (#​2726)

    In some rare case of @requires, an over-eager optimisation was incorrectly considering that
    a dependency between 2 subgraph fetches was unnecessary, leading to doing 2 subgraphs queries
    in parallel when those should be done sequentially (because the 2nd query rely on results
    from the 1st one). This effectively resulted in the required fields not being provided (the
    consequence of which depends a bit on the resolver detail, but if the resolver expected
    the required fields to be populated (as they should), then this could typically result
    in a message of the form GraphQLError: Cannot read properties of null).

  • Updated dependencies [203b0a44]:

v2.5.3

Compare Source

Patch Changes

v2.5.2

Compare Source

Patch Changes

  • Remove extraneous call to span.setStatus() on a span which has already ended. (#​2697)

    In cases where a subgraph responded with an error, we would sometimes try to set
    the status of a span which had already ended. This resulted in a warning log to
    the console (but no effect otherwise). This warning should no longer happen.

  • Fix fallbackPollIntervalInMs behavior. (#​2709)

    The fallbackPollIntervalInMs serves 2 purposes:

    • it allows users to provide an Uplink poll interval if Uplink doesn't provide one
    • it allows users to use a longer poll interval that what's prescribed by Uplink

    The second bullet is how the configuration option is documented, but not how it was previously implemented. This change corrects the behavior to respect this configuration if it's provided AND is longer than the Uplink interval.

  • Updated dependencies [35179f08]:

v2.5.1

Compare Source

Patch Changes

  • Reapply #​2639: (#​2687)

    Try reusing named fragments in subgraph fetches even if those fragment only apply partially to the subgraph. Before this change, only named fragments that were applying entirely to a subgraph were tried, leading to less reuse that expected. Concretely, this change can sometimes allow the generation of smaller subgraph fetches.

    Additionally, resolve a bug which surfaced in the fragment optimization logic which could result in invalid/incorrect optimizations / fragment reuse.

  • Updated dependencies [b9052fdd]:

v2.5.0

Compare Source

Minor Changes

  • Do not run the full suite of graphQL validations on supergraphs and their extracted subgraphs by default in production environment. (#​2657)

    Running those validations on every updates of the schema takes a non-negligible amount of time (especially on large
    schema) and mainly only serves in catching bugs early in the supergraph handling code, and in some limited cases,
    provide slightly better messages when a corrupted supergraph is received, neither of which is worth the cost in
    production environment.

    A new validateSupergraph option is also introduced in the gateway configuration to force this behaviour.

  • Support responses from subgraphs which use the application/graphql-response+json content-type header. (#​2162)

    See graphql-over-http spec for more details:
    https://graphql.github.io/graphql-over-http/draft/#sec-application-graphql-response-json

  • Introduce the new @authenticated directive for composition (#​2644)

    Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @authenticated directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

    Users may now compose @authenticated applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables authenticated access to specific types and fields via directive applications.

    The directive is defined as follows:

    directive @​authenticated on FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM

    In order to compose your @authenticated usages, you must update your subgraph's federation spec version to v2.5 and add the @authenticated import to your existing imports like so:

    @​link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@​authenticated"])

  • Introduce the new @requiresScopes directive for composition (#​2649)

    Note that this directive will only be fully supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that composition of valid @requiresScopes directive applications will succeed, but the resulting supergraph will not be executable by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

    Users may now compose @requiresScopes applications from their subgraphs into a supergraph. This addition will support a future version of Apollo Router that enables scoped access to specific types and fields via directive applications.

    The directive is defined as follows:

    scalar federation__Scope

directive @​requiresScopes(
  scopes: [federation__Scope!]!
) on FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM

    The Scope scalar is effectively a String, similar to the FieldSet type.

    In order to compose your @requiresScopes usages, you must update your subgraph's federation spec version to v2.5 and add the @requiresScopes import to your existing imports like so:

    @​link(url: "https://specs.apollo.dev/federation/v2.5", import: [..., "@​requiresScopes"])
Patch Changes

v2.4.13

Compare Source

Patch Changes

v2.4.12

Compare Source

Patch Changes

  • Remove extraneous call to span.setStatus() on a span which has already ended. (#​2717)

    In cases where a subgraph responded with an error, we would sometimes try to set
    the status of a span which had already ended. This resulted in a warning log to
    the console (but no effect otherwise). This warning should no longer happen.

  • Fix fallbackPollIntervalInMs behavior. (#​2717)

    The fallbackPollIntervalInMs serves 2 purposes:

    • it allows users to provide an Uplink poll interval if Uplink doesn't provide one
    • it allows users to use a longer poll interval that what's prescribed by Uplink

    The second bullet is how the configuration option is documented, but not how it was previously implemented. This change corrects the behavior to respect this configuration if it's provided AND is longer than the Uplink interval.

  • Updated dependencies [693c2433]:

v2.4.11

Compare Source

Patch Changes

  • Reapply #​2639: (#​2684)

    Try reusing named fragments in subgraph fetches even if those fragment only apply partially to the subgraph. Before this change, only named fragments that were applying entirely to a subgraph were tried, leading to less reuse that expected. Concretely, this change can sometimes allow the generation of smaller subgraph fetches.

    Additionally, resolve a bug which surfaced in the fragment optimization logic which could result in invalid/incorrect optimizations / fragment reuse.

  • Updated dependencies [a740e071]:

v2.4.10

Compare Source

Patch Changes

v2.4.9

Compare Source

Patch Changes

v2.4.8

Compare Source

Patch Changes

v2.4.7

Compare Source

Patch Changes

v2.4.6

Compare Source

Patch Changes

v2.4.5

Compare Source

Patch Changes

v2.4.4

Compare Source

Patch Changes

v2.4.3

Compare Source

Patch Changes

v2.4.2

Compare Source

Patch Changes
  • Fix potential bug when an @interfaceObject type has a @requires. When an @interfaceObject type has a field with a (#​2524)
    @requires and the query requests that field only for some specific implementations of the corresponding interface,
    then the generated query plan was sometimes invalid and could result in an invalid query to a subgraph (against a
    subgraph that rely on @apollo/subgraph, this lead the subgraph to produce an error message looking like "The _entities resolver tried to load an entity for type X, but no object or interface type of that name was found in the schema").
  • Updated dependencies [2c370508, 179b4602]:

v2.4.1

Compare Source

Patch Changes

v2.4.0

Compare Source

Minor Changes

  • This change introduces a configurable query plan cache. This option allows (#​2385)
    developers to provide their own query plan cache like so:

    new ApolloGateway({
  queryPlannerConfig: {
    cache: new MyCustomQueryPlanCache(),
  },
});

    The current default implementation is effectively as follows:

    import { InMemoryLRUCache } from "@​apollo/utils.keyvaluecache";

const cache = new InMemoryLRUCache<string>({
  maxSize: Math.pow(2, 20) * 30,
  sizeCalculation<T>(obj: T): number {
    return Buffer.byteLength(JSON.stringify(obj), "utf8");
  },
});

    TypeScript users should implement the QueryPlanCache type which is now
    exported by @apollo/query-planner:

    import { QueryPlanCache } from '@&#8203;apollo/query-planner';

class MyCustomQueryPlanCache implements QueryPlanCache {
  // ...
}

  • Adds debug/testing query planner options (debug.bypassPlannerForSingleSubgraph) to bypass the query planning (#​2441)
    process for federated supergraph having only a single subgraph. The option is disabled by default, is not recommended
    for production, and is not supported (it may be removed later). It is meant for debugging/testing purposes.

Patch Changes

v2.3.6

Compare Source

Patch Changes

  • Handle defaulted variables correctly during post-processing. (98844fd5)

    Users who tried to use built-in conditional directives (skip/include) with defaulted variables and no variable provided would encounter an error thrown by operation post-processing saying that the variables weren't provided. The defaulted values went unaccounted for, so the operation would validate but then fail an assertion while resolving the conditional.

    With this change, defaulted variable values are now collected and provided to post-processing (with defaults being overwritten by variables that are actually provided).

  • Fix issues (incorrectly rejected composition and/or subgraph errors) with @interfaceObject. Those issues may occur (11f2d7c0)
    either due to some use of @requires in an @interfaceObject type, or when some subgraph S defines a type that is an
    implementation of an interface I in the supergraph, and there is an @interfaceObject for I in another subgraph,
    but S does not itself defines I.

  • Fix handling of aliases and variables in introspection queries. (ef5c8170)

  • Fix potential bug when an @interfaceObject type has a @requires. When an @interfaceObject type has a field with a (2894a1ea)
    @requires and the query requests that field only for some specific implementations of the corresponding interface,
    then the generated query plan was sometimes invalid and could result in an invalid query to a subgraph (against a
    subgraph that rely on @apollo/subgraph, this lead the subgraph to produce an error message looking like "The _entities resolver tried to load an entity for type X, but no object or interface type of that name was found in the schema").

  • Updated dependencies [98844fd5, 11f2d7c0, c0412fd9, 2894a1ea, ce0459a6]:

v2.3.5

Compare Source

Patch Changes

v2.3.4

Compare Source

Patch Changes

  • Handle defaulted variables correctly during post-processing. (#​2443)

    Users who tried to use built-in conditional directives (skip/include) with defaulted variables and no variable provided would encounter an error thrown by operation post-processing saying that the variables weren't provided. The defaulted values went unaccounted for, so the operation would validate but then fail an assertion while resolving the conditional.

    With this change, defaulted variable values are now collected and provided to post-processing (with defaults being overwritten by variables that are actually provided).

  • Updated dependencies [6e2d24b5]:

v2.3.3

Compare Source

Patch Changes

  • Update @​apollo/utils.logger typings dependency (#​2269)

  • Exposes, for each subgraph request, the path in the overall gateway operation at which that subgraph request gets inserted. This path is now available as the pathInIncomingRequest field in the arguments of RemoteGraphQLDataSource.willSendRequest and RemoteGraphQLDataSource.didReceiveResponse. (#​2384)

  • Previously the queryPlanStoreKey was a hash of the query concatenated with an unhashed operationName if it was present. This resulted in variable length cache keys that could become unnecessarily long, occupying additional space in the query plan cache. (#​2310)

    This change incorporates the operationName into the hash itself (if operationName is present).

  • Update @​apollo/utils.createhash package, which drops support for node 12 (#​2266)

  • Update @​apollo/utils.isnodelike package, which dropped support for node 12 (#​2268)

  • Update @​apollo/utils.fetcher package, which drops support for node 12 (#​2267)

  • Updated dependencies [71a07f30]:

v2.3.2

Compare Source

Patch Changes

v2.3.1

Compare Source

Patch Changes

  • Capture non-ftv1 error information in metrics data. This (#​2242)
    error information allows the inline trace plugin to correctly
    aggregate stats about errors (where no federated trace data
    is available) and stop reporting incomplete traces which
    are missing unavailable error information.

    This PR is a precursor to apollographql/apollo-server#7136

  • Fix issue where the query planner was incorrectly not querying __typename in a subgraph fetch when @interfaceObject is involved (#​2366)

  • Updated dependencies [[7e2ca46f](https://togithub.com/apollographql/federati

Configuration

📅 Schedule: 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 has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from ff874d9 to b89fe74 Compare March 7, 2022 11:59
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from b89fe74 to b535a80 Compare March 26, 2022 12:40
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from b535a80 to 8c7c7cc Compare April 24, 2022 18:25
@renovate renovate bot changed the title chore(deps): update dependency apollo-server to v3 chore(deps): update apollo graphql packages (major) Apr 24, 2022
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 8c7c7cc to 06d5c7c Compare May 15, 2022 18:51
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 06d5c7c to 911b0cc Compare June 18, 2022 22:17
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 911b0cc to 023ca11 Compare September 25, 2022 10:42
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 023ca11 to 523d518 Compare November 20, 2022 17:19
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 523d518 to 7272f71 Compare March 16, 2023 07:39
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 7272f71 to 5faad82 Compare March 23, 2023 23:26
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 5faad82 to b71f22d Compare April 17, 2023 12:53
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from 643106c to d0ef020 Compare May 30, 2023 21:30
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from d0ef020 to a2c4637 Compare June 15, 2023 23:33
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from a2c4637 to a92dbd5 Compare July 7, 2023 18:42
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 4 times, most recently from a861152 to bb1c921 Compare July 20, 2023 00:41
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from ee269a7 to 3f7671a Compare August 4, 2023 21:49
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 3 times, most recently from 3693df1 to 1d54260 Compare August 25, 2023 20:49
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from 6be7a61 to 83d80a7 Compare August 31, 2023 18:22
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 83d80a7 to 8b1ff07 Compare September 18, 2023 23:21
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 8b1ff07 to 839d0da Compare October 13, 2023 21:30
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from ead42b7 to 7520222 Compare November 17, 2023 01:43
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 7520222 to 3064bd5 Compare November 27, 2023 22:21
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 3064bd5 to 2cd55cf Compare December 12, 2023 00:51
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 2cd55cf to 0ede760 Compare January 11, 2024 16:32
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch 2 times, most recently from b0069c0 to 11299f9 Compare January 24, 2024 18:01
@renovate renovate bot force-pushed the renovate/major-apollo-graphql-packages branch from 11299f9 to f89acc0 Compare March 21, 2024 21:22
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

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant