-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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.
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
fix(deps): update apollo graphql packages #12253
Open
renovate
wants to merge
1
commit into
master
Choose a base branch
from
renovate/apollo-graphql-packages
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
4 times, most recently
from
August 22, 2023 18:27
dd4a427
to
04746e8
Compare
Pull Request Test Coverage Report for Build 0ea309b0-c169-49be-a66f-6594f5466c39Details
💛 - Coveralls |
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
6 times, most recently
from
August 30, 2023 15:26
dc8ae3b
to
31b1902
Compare
renovate
bot
changed the title
fix(deps): update apollo graphql packages
fix(deps): update apollo graphql packages to v2.5.3
Aug 31, 2023
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
3 times, most recently
from
August 31, 2023 19:08
55888cb
to
4404776
Compare
renovate
bot
changed the title
fix(deps): update apollo graphql packages to v2.5.3
fix(deps): update apollo graphql packages to v2.5.4
Aug 31, 2023
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
September 18, 2023 21:55
4404776
to
07257a1
Compare
renovate
bot
changed the title
fix(deps): update apollo graphql packages to v2.5.4
fix(deps): update apollo graphql packages to v2.5.5
Sep 18, 2023
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
3 times, most recently
from
September 28, 2023 16:20
d55b486
to
0fcb408
Compare
renovate
bot
changed the title
fix(deps): update apollo graphql packages to v2.5.5
fix(deps): update apollo graphql packages
Oct 4, 2023
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
3 times, most recently
from
October 10, 2023 00:37
9e4a6f6
to
95fb173
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
3 times, most recently
from
October 15, 2023 16:50
e50dabc
to
8b90b4c
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
October 23, 2023 10:09
8b90b4c
to
a7e4d92
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
4 times, most recently
from
January 31, 2024 08:50
daccfdd
to
e91a633
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
2 times, most recently
from
February 12, 2024 08:33
1beb9b3
to
35e5123
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
March 5, 2024 21:21
35e5123
to
289a174
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
2 times, most recently
from
March 22, 2024 21:20
7aeb10f
to
3cf50e4
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
4 times, most recently
from
April 22, 2024 10:41
90bb9d9
to
09c64c8
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
2 times, most recently
from
May 8, 2024 08:27
11afe2e
to
c4e537d
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
May 10, 2024 15:49
c4e537d
to
4636536
Compare
|
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
2 times, most recently
from
May 17, 2024 00:57
e5922a8
to
3f81ece
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
May 29, 2024 06:26
3f81ece
to
595b7ce
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
June 18, 2024 20:19
595b7ce
to
6631771
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
June 28, 2024 22:47
6631771
to
edeca72
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
July 13, 2024 01:01
edeca72
to
7652668
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
2 times, most recently
from
July 25, 2024 22:12
e0569f5
to
e9a32bd
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
August 8, 2024 18:59
e9a32bd
to
8289203
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
2 times, most recently
from
August 27, 2024 18:20
daf015b
to
26e506c
Compare
renovate
bot
force-pushed
the
renovate/apollo-graphql-packages
branch
from
August 27, 2024 21:40
26e506c
to
45bd607
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
2.4.8
->2.9.0
2.2.3
->2.9.0
4.9.3
->4.11.0
2.4.8
->2.9.0
2.2.3
->2.9.0
Release Notes
apollographql/federation (@apollo/gateway)
v2.9.0
Compare Source
Patch Changes
Avoid type explosion for inline fragments where the type condition is an interface that implements the parent type. (#3122)
Reduce memory overhead during satisfiability checking when there are many options. (#3109)
Updated dependencies [
02c2a34a62c3717a4885449172e404f19ebf66c9
,0ccfd937d4b4a576f890665ceebbd7986fac5d0c
,e0a5075c0d12a0e2f7ef303b246e3216a139d3e0
]:v2.8.5
Compare Source
v2.8.4
Compare Source
Patch Changes
4d9e0f6390c5114132d205ab73b6aa1b9ffa8cd8
,5f4bb160d024678d6facd471c43c8ec61c86e701
,672aca7cbeb0a6a38586357a4e154f2dd91caa0c
]:v2.8.3
Compare Source
Patch Changes
38debcf2f9af1a719bd1c8acbd9335efa8427ddb
,50d648ccffb05591878de75dc5522914ed48698f
,860aace9904e787f9bf05aad94be5b5920f10543
,67b70c6e68b1cdbf8f03dacafd636e27ed9b7814
,f753d55e9a49d11389ee4f8d7976533447e95ede
,f5f6a799d6b3675eecb0eaec7a816d746cd136b2
,42bd27af6a23bcfdd36951dbfa3fb9f7ba833f3a
,f376447a820e3c0ae41d16d1fd3b681d2f1e8c14
,3af790517d662f3bec9064c0bf243014c579e9cd
]:v2.8.2
Compare Source
Patch Changes
b2e5ab66f84688ec304cfcf2c6f749c86aded549
]:v2.8.1
Compare Source
Patch Changes
61f2b6b12ee83e7ecb6509f7131f9412a37e194b
]:v2.8.0
Compare Source
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)Patch Changes
Various set context bugfixes (#3017)
Updated dependencies [
c4744da360235d8bb8270ea048f0e0fa5d03be1e
,8a936d741a0c05835ff2533714cf330d18209179
,daf36bd242ba4db0cfcf0e18c1eed235ff0dfaf2
]:v2.7.8
Compare Source
Patch Changes
Triggering a clean 2.7.8 release now that harmonizer build has been fixed. (#3010)
Updated dependencies [
2ad72802044310a528e8944f4538efe519424504
]:v2.7.7
Compare Source
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
Compare Source
Patch Changes
856a82b1deca625b75145edd6328bed23abee33a
]:v2.7.5
Compare Source
Patch Changes
af4376f348d21ad4d8eca0e3d2a170600f391e4d
]:v2.7.4
Compare Source
Patch Changes
d80b7f0ca1456567a0866a32d2b2abf940598f77
,c89d8287e88d12cfd34c1baf1f42db672731b8a7
]:v2.7.3
Compare Source
Patch Changes
ec04c50b4fb832bfd281ecf9c0c2dd7656431b96
,3e2c845c74407a136b9e0066e44c1ad1467d3013
,a494631918156f0431ceace74281c076cf1d5d51
]:v2.7.2
Compare Source
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
Compare Source
Patch Changes
493f5acd16ad92adf99c963659cd40dc5eac1219
]: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: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
6ae42942b13dccd246ccc994faa2cb36cd62cb3c
,66833fb8d04c9376f6ed476fed6b1ca237f477b7
,931f87c6766c7439936df706727cbdc0cd6bcfd8
]:v2.6.3
Compare Source
Patch Changes
038cf0dbbfb0e2978b69f0a14bfd2c38b0cd1326
,69495b4810f3268c45a31f9d12e4f9cde2c447b5
]:v2.6.2
Compare Source
Patch Changes
7b5b836d15247c997712a47847f603aa5887312e
,74ca7dd617927a20d79b824851f7651ef3c40a4e
,ffe67dfbdb77d15dde2ab6dee66dba05c7b5c037
]:v2.6.1
Compare Source
Patch Changes
0d5ab01a
]:v2.6.0
Compare Source
Minor Changes
Add more information to OpenTelemetry spans. (#2700)
Rename
operationName
tographql.operation.name
and add agraphql.operation.type
attribute, in conformance with the OpenTelemetrySemantic Conventions for GraphQL. The
operationName
attribute is nowdeprecated, but it is still emitted alongside
graphql.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 eventreporting, add the following entries to your
ApolloGateway
instanceconfiguration:
Update
license
field inpackage.json
to useElastic-2.0
SPDX identifier (#2741)Introduce the new
@policy
scope for composition (#2818)Users may now compose
@policy
applications from their subgraphs into a supergraph.The directive is defined as follows:
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
b18841be
,e325b499
]:v2.5.7
Compare Source
Patch Changes
a0bdd7cb
]:v2.5.6
Compare Source
Patch Changes
c719214a
]: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.:
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 thata 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
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
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: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)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:
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)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:
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
fe1e3d7b
,aac2893a
,6b18af50
,9396c0d6
,2b5796a9
,4f3c3b9e
]:v2.4.13
Compare Source
Patch Changes
f2264cf6
]: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: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
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
Compare Source
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
]:apollographql/apollo-server (@apollo/server)
v4.11.0
Compare Source
Minor Changes
#7916
4686454
Thanks @andrewmcgivery! - AddhideSchemaDetailsFromClientErrors
option to ApolloServer to allow hiding 'did you mean' suggestions from validation errors.Even with introspection disabled, it is possible to "fuzzy test" a graph manually or with automated tools to try to determine the shape of your schema. This is accomplished by taking advantage of the default behavior where a misspelt field in an operation
will be met with a validation error that includes a helpful "did you mean" as part of the error text.
For example, with this option set to
true
, an error would readCannot query field "help" on type "Query".
whereas with this option set tofalse
it would readCannot query field "help" on type "Query". Did you mean "hello"?
.We recommend enabling this option in production to avoid leaking information about your schema to malicious actors.
To enable, set this option to
true
in yourApolloServer
options:v4.10.5
Compare Source
Patch Changes
#7821
b2e15e7
Thanks @renovate! - Non-major dependency updates#7900
86d7111
Thanks @trevor-scheer! - Inline a small dependency that was causing build issues for ESM projectsv4.10.4
Compare Source
Patch Changes
18a3827
Thanks @tninesling! - Subscription heartbeats are initialized prior to awaiting subscribe(). This allows long-running setup to happen in the returned Promise without the subscription being terminated prior to resolution.v4.10.3
Compare Source
Patch Changes
5f335a5
Thanks @tninesling! - Catch errors thrown by subscription generators, and gracefully clean up the subscription instead of crashing.v4.10.2
Compare Source
Patch Changes
c7e514c
Thanks @TylerBloom! - In the subscription callback server plugin, terminating a subscription now immediately closes the internal async generator. This avoids that generator existing after termination and until the next message is received.v4.10.1
Compare Source
Patch Changes
72f568e
Thanks @bscherlein! - Improves timing of thewillResolveField
end hook on fields which return Promises resolving to Arrays. This makes the use of thesetCacheHint
method more reliable.v4.10.0
Compare Source
Minor Changes
#7786
869ec98
Thanks @ganemone! - Restore missing v1skipValidation
option asdangerouslyDisableValidation
. Note that enabling this option exposes your server to potential security and unexpected runtime issues. Apollo will not support issues that arise as a result of using this option.#7803
e9a0d6e
Thanks @favna! - allowstringifyResult
to return aPromise<string>
Users who implemented the
stringifyResult
hook can now expect error responses to be formatted with the hook as well. Please take care when updating to this version to ensure this is the desired behavior, or implement the desired behavior accordingly in yourstringifyResult
hook. This was considered a non-breaking change as we consider that it was an oversight in the original PR that introducedConfiguration
📅 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.
This PR was generated by Mend Renovate. View the repository job log.