The issue was the following:

• https://github.com/hibernate/hibernate-validator/blob/445b3e5c73168fb75ebb3ceb4ff54ab9dd921ee0/engine/src/main/java/org/hibernate/validator/internal/engine/valueextraction/ValueExtractorResolver.java#L305 we try to get the element from the cache
• if we get it, instead of returning it directly (which is what we do now), we continue the logic
• if it was already in the cache then it was already a set wrapped in an immutable set
• then here https://github.com/hibernate/hibernate-validator/blob/445b3e5c73168fb75ebb3ceb4ff54ab9dd921ee0/engine/src/main/java/org/hibernate/validator/internal/engine/valueextraction/ValueExtractorResolver.java#L320 , we wrap the element again in an immutable set and we put it back in the cache

In the end, you end up with an immutable set of an immutable of an immutable set... of the original set. After a certain period of time, you have so many immutable wrappers than just calling isEmpty() causes a stack overflow.

It only happens with Maps because CollectionHelper#toImmutableSet() has special cases if the map is empty or has only one element.

You can reproduce it by validating what Gunnar presented above a few times and check what is in the cache. The elements in the cache should be wrapped only once, even after a few rounds of validation.