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
deps: Update dependency com.graphql-java:graphql-java to v230521 (main) - autoclosed #17781
Closed
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
github-actions
bot
added
component/zeebe
Related to the Zeebe component/team
component/operate
Related to the Operate component/team
component/tasklist
Related to the Tasklist component/team
labels
Apr 24, 2024
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Apr 24, 2024
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
from
April 24, 2024 22:20
1b3cab6
to
2fb66e0
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to a conflict with the base branch
Apr 24, 2024
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
from
April 24, 2024 23:12
2fb66e0
to
16e21e2
Compare
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
12 times, most recently
from
April 25, 2024 14:54
35244e6
to
de9d386
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Apr 25, 2024
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
from
April 25, 2024 15:33
de9d386
to
b813944
Compare
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
from
April 25, 2024 17:00
b813944
to
99db604
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Apr 25, 2024
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
from
April 25, 2024 18:25
99db604
to
8b3a412
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Apr 25, 2024
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
from
April 25, 2024 19:55
8b3a412
to
87deddd
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Apr 25, 2024
matt-whiteman
requested changes
Apr 25, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Appears to be causing a dependency convergence error, see https://github.com/camunda/zeebe/actions/runs/8823525333/job/24224603636
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
from
April 25, 2024 20:48
87deddd
to
364f86e
Compare
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
10 times, most recently
from
April 26, 2024 01:54
5f904d5
to
d037976
Compare
renovate
bot
force-pushed
the
renovate/main-major-version.graphql-java
branch
from
April 26, 2024 04:08
d037976
to
827a8e1
Compare
auto-merge was automatically disabled
April 26, 2024 07:12
Pull request was closed
renovate
bot
changed the title
deps: Update dependency com.graphql-java:graphql-java to v230521 (main)
deps: Update dependency com.graphql-java:graphql-java to v230521 (main) - autoclosed
Apr 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
automerge
component/operate
Related to the Operate component/team
component/tasklist
Related to the Tasklist component/team
component/zeebe
Related to the Zeebe component/team
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:
21.5
->230521-nf-execution
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
graphql-java/graphql-java (com.graphql-java:graphql-java)
v22.0
: 22.0Compare Source
We are pleased to announce the release of graphql-java v22.0.
Thanks to everyone in the community who contributed to the release, whether that was code, helping to report issues, or participating in discussions.
This is a breaking change release.
The graphql-java team takes breaking changes very seriously but in the name of performance we have made some significant breaking changes in this release.
Major Performance Changes
Past releases have been very much performance focused and this one is no different. However, this release is aiming to reduce memory pressure more than reduce pure CPU usage. When the graphql-java engine is running, if it produces less objects it will ultimately run faster because of reduced memory pressure and less garbage to collect.
The engine has been changed in two major ways that reduce memory pressure.
ExecutionResult wrapping
The first was that all values that come back got wrapped internally into a
ExecutionResult
object where thedata
attribute was the value. This was a carry over from some very early GraphQL code but was unnecessary and hence has been removed. The follow on effect of this is that somegraphql.execution.ExecutionStrategy
protected methods andgraphql.execution.instrumentation.Instrumentation
methods used to receive and returnExecutionResult
values and no longer do, which is an API breaking change. We have made this breaking changes in the name of memory pressure performance.CompletableFuture wrapping
The second major change is that the engine no longer exclusively uses
java.util.concurrent.CompletableFuture
s when composing together results. Let us explain the past code first so we can discuss the new code.CompletableFuture
is a fantastic construct because it represents a promise to a value and it can also hold an exceptional state inside itself. Async programming withCompletableFuture
is viral. If stage 1 of some compute process returns aCompletableFuture
then stage 2 and 3 and 4 are likely to as well to ensure everything is asynchronous.We use to take values that were not asynchronous (such as DataFetcher that returned a simple in memory object) and wrap them in a
CompletableFuture
so that all of the other code composed together usingCompletableFuture
methods like.thenApply()
and.thenCompose
and so on. The code is cleaner if you use allCompletableFuture
code patterns.However many objects in a GraphQL request are not asynchronous but rather materialised objects in memory. Scalars, enums and list are often just values immediately available to be used and allocating a
CompletableFuture
makes the code easier to write but it has a memory pressure cost.So we have sacrificed cleaner code for more memory performant code.
graphql-java engine
graphql.execution.ExecutionStrategy
methods now just returnObject
where that object might be either aCompletableFuture
or a materialised value.Notice we have lost type safety here. In the past this would have only been
CompletableFuture<FetchedValue>
and hence been both type safe and async composable.Now the caller of that method has to handle the async case where it might be a
CompletableFuture<FetchedValue>
AND the materialised value case where it might be aFetchedValue
but as most simple fields in GraphQL are in fact materialised values, this is worth the less clean code.DataFetchers
can of course continue to returnCompletableFuture
values and they will be handled in a polymorphic manner.The upshot of all this work is that the graphql-java engine allocated way less
CompletableFuture
values and hence reduces the amount of memory used.Instrumentation Changes
The above changes now mean means that before
graphql.execution.instrumentation.InstrumentationContext
used to be given aCompletableFuture
but now no longer doesis now
if you previously used the
CompletableFuture
to know when something was completed, wellInstrumentationContext
has the same semantics because it's completed method is similar in that it presents a value or an exceptiongraphql.execution.instrumentation.Instrumentation
also had a lot of deprecated methods in place and these have been removed since the more performant shape of passing ingraphql.execution.instrumentation.InstrumentationState
has been in place for quite a few releases.Some of the methods that received
ExecutionResult
wrapped values have also changed as mentioned above.Instrumentation
is probably the area that needs the most attention in terms of breaking changes. If you have not moved off the deprecated methods, your customInstrumentation
s will no longer compile or run.Interning key strings
Our friends at Netflix provided a PR that interns certain key strings like "field names" so that we create less String instances when processing field names in queries that we know must be previously interned in the schema.
https://github.com/graphql-java/graphql-java/pull/3504
The full list of performance related changes
https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A%2222.0%22+label%3Aperformance
Major Changes
@defer Experimental Support
Support for the
@defer
directive has been added in an experimental fashion. While@defer
is still not in the released GraphQL specification, we have judged it mature enough to support at this stage and thegraphql-js
reference implementation has support for it.https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferStream.md
At this stage we have not yet supported
@stream
but this is likely to be included in a future release.Breaking Changes
There are quite a few API breaking changes in this release. In fact there are 22 PRs containing breaking API changes.
Stricter parseValue coercion: Aligning with JS reference implementation
We have made changes to String, Boolean, Float, and Int
parseValue
coercion, to be consistent with the reference JS implementation. The key change isparseValue
is now stricter on accepted inputs.parseValue
now requires input of typeString
. For example, aNumber
input123
or aBoolean
inputtrue
will no longer be accepted.parseValue
now requires input of typeBoolean
. For example, aString
input"true"
will no longer be accepted.parseValue
now requires input of typeNumber
. For example, aString
input"3.14"
will no longer be accepted.parseValue
now requires input of typeNumber
. For example, aString
input"42"
will no longer be accepted.This is a breaking change. To help you migrate, in version 21.0, we introduced the InputInterceptor https://github.com/graphql-java/graphql-java/pull/3188 (and an implementation LegacyCoercingInputInterceptor https://github.com/graphql-java/graphql-java/pull/3218) to provide a migration pathway. You can use this interceptor to monitor and modify values.
For more, see https://github.com/graphql-java/graphql-java/pull/3553
JS reference implementation: https://github.com/graphql/graphql-js/blob/main/src/type/scalars.ts
Removing deprecated methods
Many methods that have been deprecated for a long time, sometimes even up to 6 years, have finally been removed.
The
CompletableFuture
unwrapping work mentioned above changed many methods in thegraphql.execution.ExecutionStrategy
classes but we don't expect this affect many people since very few people write their own engines.That
CompletableFuture
unwrapping work also had knock on effects as mentioned above ongraphql.execution.instrumentation.Instrumentation
and hence this is the most likely place for there to be compatibility challenges in existing code.DataLoaderDispatcherInstrumentation has been removed and is now built into the engine
The code to dispatch
org.dataloader.DataLoader
s used to be an instrumentation calledDataLoadersDataLoaderDispatcherInstrumentation
and it was automatically added at runtime. This approach has been removed.The equivalent code is now built into the graphql-java engine itself.
DataLoader
s can now always be used without any special setup. This also allows the code to be more performant in howDataLoader
s are dispatched.SL4J logging has been removed
Previously, the graphql-java engine would log at DEBUG level certain errors or when fields get fetched. This has not proven used for from a support point to the graphql-java team and also has a compliance cost in that user generated content (UGC) and personally identifying information (PII) could end up being logged, which may not be allowed under regimes like European General Data Protection Regulation (GDPR).
If you want to log now we suggest you invest in a
Instrumentation
that logs key events and you can there for log what you want and in a compliant manner of your choosing.https://github.com/graphql-java/graphql-java/pull/3403
The full list of API breaking changes
https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A%2222.0%22+label%3A%22breaking+change%22
Other changes
What's Changed
New Contributors
Full Changelog: graphql-java/graphql-java@v21.5...v22.0
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.