It is possible to cause stack overflow with custom groups sequence for beans with circular reference.
As seen in my test case (below) validation of object graph with a loop might blow the stack.
Supposedly, there are two reasons:
This forced CachingTraversableResolverForSingleValidation to return false-positive for node in a loop.
For my test case it causes traversables to return cached object regardless of actual path in object (pathToTraversableObject.toString() - bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean.yourAnnotatedBean.bean)
HV 5 it was less of an issue, since our custom traversable resolver was called, which gave us a chance to control the validation flow.
Custom groups enables ValidatorImpl.validateConstraintsForDefaultGroup() to override group sequence and if default group is not last in this list, it causes validationContext.markCurrentBeanAsProcessed( valueContext ) to mark wrong group in processedGroupUnits. When it cascades to next level with default group, which is getting replaced with custom constrain and marked as processed (and so on)...
The bean is never returned as processed for default group.
It is possible to workaround issue by re-arranging groups.
I just released 6.0.15.Final with the fix for this bug (thanks go to for the fix!).
It should be synced to Maven Central tomorrow latest. Hopefully, you will be able to upgrade to 6.x then.