Hibernate FetchNotFoundException

[fabrii]

Describe the bug

After upgrading to Quarkus >= 3.14.0, some save operations started to fail with the following error:

Caused by: org.hibernate.FetchNotFoundException: Entity `com.x.y.entity` with identifier value `2` does not exist
        at org.hibernate.sql.results.graph.entity.internal.EntityInitializerImpl.setMissing(EntityInitializerImpl.java:661)
        at org.hibernate.sql.results.graph.entity.internal.EntityInitializerImpl.resolveFromPreviousRow(EntityInitializerImpl.java:674)
        at org.hibernate.sql.results.graph.entity.internal.EntityInitializerImpl.resolveFromPreviousRow(EntityInitializerImpl.java:94)

Check also this comment #42902 (comment)

The error is also happening with quarkus.hibernate-orm.flush.mode=always

This seems to be related to the Hibernate 6.6 update.

Expected behavior

Save correctly, as previous Quarkus versions. It is working in <= 3.13.3

Actual behavior

No response

How to Reproduce?

https://github.com/fabrii/quarkus-playground/tree/FetchNotFoundException

It has something to do with detached entities, and optional = false annotation.

For example,

In Module class,

@ManyToOne(optional = false)
@JoinColumn(name = "sistema_id")
private System system;

if the optional=false tag is removed, the test works.

This reproducer works correctly on Quarkus <= 3.13.3

Output of uname -a or ver

No response

Output of java -version

openjdk version "21.0.2"

Quarkus version or git rev

= 3.14.0

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

No response

Additional information

No response

[quarkus-bot]

/cc @gsmet (hibernate-orm), @yrodiere (hibernate-orm)

[yrodiere]

Thanks for reporting.

I tried this locally, and (after a few fixes) managed to get the same error, but upgrading to ORM 6.6.2 seems to resolve the issue: https://github.com/yrodiere/quarkus-playground/tree/FetchNotFoundException-fixes

I'll close this as a duplicate of #7462, which should get resolved by #44391.

[yrodiere]

Actually you know what, the cause is similar (some issue in the merge code) but may not be the same, since the thrown exception is not the same either... I'll just leave this open and mark it as fixed by #44391.