Yes, I agree, even a slight change to the merge behavior, such as not to swap in a proxy where it once did (hypothetically) during merge would be all it would take to mess up everything downstream. On the other hand, if this were the case, we’d probably be seeing a substantial increase in NullPointerExceptions anywhere we previously could rely on having a proxy.
We did move from Hibernate ORM 5.4.15 to version 5.5.6 when we integrated Hibernate Search 6. Javassist went from 3.24 to 3.27.
It seems like there have been times over the years when refresh() and find() would not provide live/hot proxies for initialization right after a persist or merge, without a prior call to evict() and/or refresh(). Then later we noticed that refresh() seemed to get smarter, i.e. it started doing a more thorough job of fixing up a detached instance.
At times I have wished that find(), persist() and merge() would always convert every null relation to a proxy, so I could remove a lot of boilerplate code, but then I got used to using evict() / refresh() or evict() and find() just about every time I would need to traverse a relationship next…
Of course the query cache and second level object cache all had their own respective roles to play in how this functionality would return results in a performant manner. This probably varied as well if we had changed configuration.
Hibernate is always getting better and better, so hopefully whatever change we need to make will stay the same for a while.
I’d hate to have to hit the database every time, just to get live proxies, but again, the second level cache will probably help that perform well if we need to do that to get the system back to normal, even in the short term.