supergraph-demo
supergraph-demo copied to clipboard
fix(deps): update apollo graphql packages to v2 (major)
This PR contains the following updates:
Package | Change | Age | Adoption | Passing | Confidence |
---|---|---|---|---|---|
@apollo/gateway (source) | 0.54.1 -> 2.8.2 |
||||
@apollo/subgraph (source) | 0.6.1 -> 2.8.2 |
Release Notes
apollographql/federation (@apollo/gateway)
v2.8.2
Patch Changes
- Updated dependencies [
b2e5ab66f84688ec304cfcf2c6f749c86aded549
]:
v2.8.1
Patch Changes
- Updated dependencies [
61f2b6b12ee83e7ecb6509f7131f9412a37e194b
]:
v2.8.0
Minor Changes
-
Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the
prop
field within the Child resolver. (#2988)type Query { p: Parent! } type Parent @​key(fields: "id") @​context(name: "context") { id: ID! child: Child! prop: String! } type Child @​key(fields: "id") { id: ID! b: String! field(a: String @​fromContext(field: "$context { prop }")): Int! }
Patch Changes
-
Various set context bugfixes (#3017)
-
Updated dependencies [
c4744da360235d8bb8270ea048f0e0fa5d03be1e
,8a936d741a0c05835ff2533714cf330d18209179
,daf36bd242ba4db0cfcf0e18c1eed235ff0dfaf2
]:
v2.7.8
Patch Changes
-
Triggering a clean 2.7.8 release now that harmonizer build has been fixed. (#3010)
-
Updated dependencies [
2ad72802044310a528e8944f4538efe519424504
]:
v2.7.7
Patch Changes
-
No logical changes since 2.7.5 or 2.7.6, but we fixed a bug in the release process, so we need to publish a new patch version (2.7.7). (#2999)
-
Updated dependencies [
bee0b0828b4fb6a1d3172ac330560e2ab6c046bb
]:
v2.7.6
Patch Changes
- Updated dependencies [
856a82b1deca625b75145edd6328bed23abee33a
]:
v2.7.5
Patch Changes
- Updated dependencies [
af4376f348d21ad4d8eca0e3d2a170600f391e4d
]:
v2.7.4
Patch Changes
- Updated dependencies [
d80b7f0ca1456567a0866a32d2b2abf940598f77
,c89d8287e88d12cfd34c1baf1f42db672731b8a7
]:
v2.7.3
Patch Changes
- Updated dependencies [
ec04c50b4fb832bfd281ecf9c0c2dd7656431b96
,3e2c845c74407a136b9e0066e44c1ad1467d3013
,a494631918156f0431ceace74281c076cf1d5d51
]:
v2.7.2
Patch Changes
-
Remove out-of-band reporting in the gateway and provide a warning for users who have the endpoint configured. (#2946)
-
Updated dependencies [
33b937b18d3c7ca6af14b904696b536399e597d1
,09cd3e55e810ee513127b7440f5b11af7540c9b0
,d7189a86c27891af408d3d0184db6133d3342967
,33506bef6d755c58400081824167711c1747ee40
,1f72f2a361a83ebaaf15ae052f5ca9a93fc18bfc
]:
v2.7.1
Patch Changes
- Updated dependencies [
493f5acd16ad92adf99c963659cd40dc5eac1219
]:
v2.7.0
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
- Updated dependencies [
6ae42942b13dccd246ccc994faa2cb36cd62cb3c
,66833fb8d04c9376f6ed476fed6b1ca237f477b7
,931f87c6766c7439936df706727cbdc0cd6bcfd8
]:
v2.6.3
Patch Changes
- Updated dependencies [
038cf0dbbfb0e2978b69f0a14bfd2c38b0cd1326
,69495b4810f3268c45a31f9d12e4f9cde2c447b5
]:
v2.6.2
Patch Changes
- Updated dependencies [
7b5b836d15247c997712a47847f603aa5887312e
,74ca7dd617927a20d79b824851f7651ef3c40a4e
,ffe67dfbdb77d15dde2ab6dee66dba05c7b5c037
]:
v2.6.1
Patch Changes
- Updated dependencies [
0d5ab01a
]:
v2.6.0
Minor Changes
-
Add more information to OpenTelemetry spans. (#2700)
Rename
operationName
tographql.operation.name
and add agraphql.operation.type
attribute, in conformance with the OpenTelemetry Semantic Conventions for GraphQL. TheoperationName
attribute is now deprecated, but it is still emitted alongsidegraphql.operation.name
.Add a
graphql.document
span attribute to thegateway.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 yourApolloGateway
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 inpackage.json
to useElastic-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 aString
, similar to theFieldSet
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
Patch Changes
- Updated dependencies [
a0bdd7cb
]:
v2.5.6
Patch Changes
- Updated dependencies [
c719214a
]:
v2.5.5
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.
v2.5.4
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 formGraphQLError: Cannot read properties of null
). -
Updated dependencies [
203b0a44
]:
v2.5.3
Patch Changes
-
Fix execution error in some cases where aliases are used and some values are
null
. (#2716)The error would manifest itself as an
INTERNAL_SERVER_ERROR
with a message of the formCannot read properties of null
. -
Updated dependencies [
4b9a512b
,c6e0e76d
,1add932c
,6f1fddb2
]:
v2.5.2
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
Patch Changes
-
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
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 aString
, similar to theFieldSet
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
Patch Changes
- Updated dependencies [
f2264cf6
]:
v2.4.12
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
Patch Changes
-
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
Patch Changes
-
Revert #2639 from v2.4.9 (#2681)
PR #2639 attempts to resolve issues with query fragment reuse, but we've since turned up multiple issues (at least 1 of which is a regression - see #2680. For now, this reverts it until we resolve the regression for a future patch release.
-
Updated dependencies [
b6be9f96
]:
v2.4.9
Patch Changes
-
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. (#2639)
-
Updated dependencies [
7ac83456
,d60349b3
,1bb7c512
,02eab3ac
,fd4545c2
]:
v2.4.8
Patch Changes
v2.4.7
Patch Changes
- Re-work the code use to try to reuse query named fragments to improve performance (thus sometimes improving query (#2604)
planning performance), to fix a possibly raised assertion error (with a message of form like
Cannot add selection of field X to selection set of parent type Y
), and to fix a rare issue where an interface or union field was not being queried for all the types it should be. - Updated dependencies [
2d44f346
]:
v2.4.6
Patch Changes
v2.4.5
Patch Changes
-
Supersedes v2.4.4 due to a publishing error with no dist/ folder (#2583)
-
Updated dependencies [
c96e24c4
]:
v2.4.4
Patch Changes
- Fix incorrect import the
assert
function in theDataRewrite.ts
. The incorrect method was imported (due to a bad (#2581) import auto-completion) and went unnoticed, leading to potential build issue. - Updated dependencies [
cb7f414d
]:
v2.4.3
Patch Changes
- Updated dependencies [
f6a8c1ce
]:
v2.4.2
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
Patch Changes
-
Revert #2639 from v2.4.9 (#2681)
PR #2639 attempts to resolve issues with query fragment reuse, but we've since turned up multiple issues (at least 1 of which is a regression - see #2680. For now, this reverts it until we resolve the regression for a future patch release.
-
Updated dependencies [
b6be9f96
]:
v2.4.0
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 '@​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
-
Refactor the internal implementation of selection sets used by the query planner to decrease the code complexity and (#2387) improve query plan generation performance in many cases.
-
Optimises query plan generation for parts of queries that can statically be known to not cross across subgraphs (#2449)
-
Updated dependencies [
260c357c
,7bc0f8e8
,d4426ff9
,a9385bdb
,1a555d98
,ade7ceb8
,09382e74
,cab383b2
]:
v2.3.6
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 subgraphS
defines a type that is an implementation of an interfaceI
in the supergraph, and there is an@interfaceObject
forI
in another subgraph, butS
does not itself definesI
. -
Fix handling of aliases and variables in introspection queries. ([
ef5c8170
](https://togithub.com/apollographql/federation/commi
Configuration
📅 Schedule: Branch creation - "after 10pm every weekday,before 5am every weekday,every weekend" (UTC), 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.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
- [ ] If you want to rebase/retry this PR, check this box
This PR has been generated by Mend Renovate. View repository job log here.