"HR000069: Detected use of the reactive Session from a different Thread" caused by missing equals/hashcode

[allertonm]

Describe the bug

There have been a few previous issues related to the HR000069 error under load, some of which are claimed to have been fixed prior to Quarkus 3.1, or closed due to lack of repro.

I'm posting this one because while it is not reproducible using Quarkus 3.2, it has very straightforward repro on Quarkus 3.1.2. I've not been able to find an issue closed for 3.2 that would explain why this is no longer reproducible, so this may be of interest to the team.

A repo containing an example app that demonstrates the problem can be found at https://github.com/allertonm/hibernate-query-bug/tree/quarkus-3.1

The main branch uses Quarkus 3.2, and the quarkus-3.1 branch uses 3.1 and can be used to demonstrate the bug.

The reproduction requires the following...

1. A persisted entity (BarEntity in this example) with a field whose value is an instance of a class (Foo2, here) that does not implement equals/hashcode
2. An endpoint that queries for that entity twice in succession within the same session

Expected behavior

Second query for the entity completes as expected.

Actual behavior

Second query for the entity throws HR000069 if two requests are executed concurrently.

How to Reproduce?

To reproduce the problem, checkout the quarkus-3.1 branch and run the application using ./gradlew quarkusDev (requires a Postgres server with a DB "bug_test" on localhost:5432)

In a shell session, create the entity...

% curl http://localhost:8083/create2 
Created 01f9f686-f47a-44e0-9727-d58cb3c54216%

Copy the UUID written to stdout and then...

seq 1 100 | xargs -P2 -Iname curl http://localhost:8083/read/<paste UUID here>

You should hit HR000069 almost immediately, usually on the first two requests.

You will not hit this error if, instead of using create2, you use create1 or create3, which set the value of BarEntity.foo to be either a Kotlin data class instance or an instance of a class with equals and hashCode implemented.

Output of uname -a or ver

Darwin M-L10KJGH6 22.5.0 Darwin Kernel Version 22.5.0: Mon Apr 24 20:51:50 PDT 2023; root:xnu-8796.121.2~5/RELEASE_X86_64 x86_64

Output of java -version

openjdk version "11.0.16" 2022-07-19 LTS OpenJDK Runtime Environment Corretto-11.0.16.8.1 (build 11.0.16+8-LTS) OpenJDK 64-Bit Server VM Corretto-11.0.16.8.1 (build 11.0.16+8-LTS, mixed mode)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.1.2

Build tool (ie. output of mvnw --version or gradlew --version)

------------------------------------------------------------ Gradle 8.1.1 ------------------------------------------------------------ Build time: 2023-04-21 12:31:26 UTC Revision: 1cf537a851c635c364a4214885f8b9798051175b Kotlin: 1.8.10 Groovy: 3.0.15 Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021 JVM: 11.0.16 (Amazon.com Inc. 11.0.16+8-LTS) OS: Mac OS X 13.4 x86_64

Additional information

No response

[geoand]

cc @DavideD

[DavideD]

I've tried to replicate this error using the project you've provided, but it works fine with both QUarkus 3.1 and Quarkus 3.2.
If it works fine with Quakurs 3.2, I think we can close this issue. A lot of bugfixes have been included in that release.

[allertonm]

Surprised you couldn't repro* though I absolutely understand why would wouldn't want to spend a lot of time on a bug that already appears fixed (and also has a workaround.)

(* it's worth noting that the repro only works with the 'create2' case, not create1 and create3.)

[DavideD]

Surprised you couldn't repro*

It's probably a question of timing. Maybe my machine is faster

create2 runs an update query, while create1 and create3 don't.
I think the problem was caused by this issue: hibernate/hibernate-reactive#1687

The fix has been included in Hibernate Reactive 2.0.2.Final. It would explain why it works with Quarkus 3.2 (it uses Hibernate Reactive 2.0.4.Final).

I'm going to consider this solved. But we can always reopen it in case there are new info about it.

Thanks a lot for the feedback, though.
It's always good to double check these kind of errors

[allertonm]

Thanks for looking into this Davide!