Well, wait, no, in fact it seems that this must indeed have been intentional, though it’s definitely fragile and surely not a great way to do things.

The reason it looks correct: I managed to easily concoct tests with a regular @ElementCollection which pass on H7 with batching both enabled and disabled, but when I “fix” the suspicious-looking code, the tests fail only with batching enabled, similar to what you reported in https://hibernate.atlassian.net/browse/HHH-19322.

Anyway, my conclusions are:

1. this was probably not wrong, but it's fragile for sure,

2. we are missing tests which identify the cases which this was trying to work around, and

3. we need to discuss as a team what is the correct expectation to have with stale updates to collections.

I think we should probably continue the discussion on the other issue, @Konrad Kuegler.

So, I mean, good catch, @Konrad Kuegler!

Uffff. Hell, I’m going to have to admit that I’m simply not certain, but it definitely looks suspicious, and I think I’m going to have to go with it must have been unintentional. It’s a bit disturbing that all tests pass either way.

While reporting/looking into https://hibernate.atlassian.net/browse/HHH-19322 I noticed that this change fixes the StaleStateException I was seeing (in 6.6) on main.

This is because with this change BatchImpl#checkRowCounts (see https://github.com/hibernate/hibernate-orm/commit/ee00217733018075ccade7e1145f45ff9acae0c2#diff-2d114406014843caac2b990c0993fc2242be51e98d5bb7ba12f31248bb2dde3cR340) now swallows StaleStateException if staleStateMappers is null like in my case. Code calling BatchImpl#addToBatchwith a null StaleStateMapper now results in such exceptions being dropped instead of (re-)thrown.
I’m bringing this up, because from the commit message/this ticket it was not obvious to me whether this was an intended change.

@Gavin King I hope it is okay to discuss this here. Was this behavior change intentional and does it make sense to use this or a similar approach to fix HHH-19322?

Done.