OS: macOS 13.5.2 (22G91) - but also in docker image: amazoncorretto:17-alpine-jdk
Current Behavior
Out setup contains an postgresql database, a reactive java 17 application and graphql controller layer.
In version 1.0.1.RELEASE we encounter a very strange and hard to reproduce bug. When we go back to version 1.0.0.RELEASE this does not happen.
More specific the bug appeared after upgrading to spring-boot-starter 3.1.4. When playing with the versions, I found out the issue can be resolved by downgrading the r2dbc-pool version to 1.0.0.RELEASE
The issue happens in certain @BatchMapping functions.
Lets take, for example, following graphql:
type Folder {
id: ID!
users:[User]
}
type User {
id: ID!
folder: Folder
}
type Query {
folder(folderId: ID!): Folder
}
The issue arises when we query a folder with a list of users 1000 times quickly after each other.
Sometimes all 1000 are as expected, sometimes a couple (3,4) fail with one or more of the users being null.
So we get f.e.
The user being null is not the same, as is the amount of failing requests.
Sorry for the quite vague issue and explanation. It was quite hard to pinpoint it and to even be able to reproduce on our systems. It seems to happen when we send large amounts of requests to the backend, and even then it behaves quite randomly. If there are any more questions, I will try to answer them as best as possible.
Steps to reproduce
Sadly I tried reproducing it on a demo application, but was unable to.
I am missing some config somewhere, but I can't find it.
I hope the explanation above helps enough to find this issue
Expected behavior/code
Each response be filled in the same without any null fields in the array.
f.e.
Bug Report
Versions
Current Behavior
Out setup contains an postgresql database, a reactive java 17 application and graphql controller layer. In version 1.0.1.RELEASE we encounter a very strange and hard to reproduce bug. When we go back to version 1.0.0.RELEASE this does not happen. More specific the bug appeared after upgrading to spring-boot-starter 3.1.4. When playing with the versions, I found out the issue can be resolved by downgrading the r2dbc-pool version to 1.0.0.RELEASE
The issue happens in certain
@BatchMapping
functions. Lets take, for example, following graphql:The issue arises when we query a folder with a list of users 1000 times quickly after each other. Sometimes all 1000 are as expected, sometimes a couple (3,4) fail with one or more of the users being
null
. So we get f.e.The user being
null
is not the same, as is the amount of failing requests.Sorry for the quite vague issue and explanation. It was quite hard to pinpoint it and to even be able to reproduce on our systems. It seems to happen when we send large amounts of requests to the backend, and even then it behaves quite randomly. If there are any more questions, I will try to answer them as best as possible.
Steps to reproduce
Sadly I tried reproducing it on a demo application, but was unable to. I am missing some config somewhere, but I can't find it. I hope the explanation above helps enough to find this issue
Expected behavior/code
Each response be filled in the same without any null fields in the array. f.e.