The GitHub Actions job "Groovy Snapshot Canary Build" on grails-core.git/fix/gorm-bean-validation-constraints has failed. Run started by GitHub user jdaugherty (triggered by jdaugherty).
Head commit for run: ab0a14663ea9f87541fade75d4816e0d49ba50fa / James Daugherty <[email protected]> End a cycle of associations at the instance it leads back to, cascade the provider from the beans it reaches and validate subclass instances with their own validator The guard keyed on validation hints let a cycle of associations lead back to the instance validation started with, or to one on the path, when it was reached with other hints, so an account validated in a group was validated again in the default group under region.office.account. A cycle now ends at an instance validation is cascading from, whatever hints it is reached with, as it did before: Cascade holds the instance and the cascade it was reached through, and cascadeValidationToOne returns when the chain leads back to the associated instance. The traversable resolver refused the persistent associations of every bean while the GORM validator cascades, including the beans the provider reached through a transient @Valid property, which GORM never reaches, so their @Valid associations were validated by nobody. It refuses them on the root bean of the provider's validation alone. The root bean is told by its path naming no property: Hibernate Validator 9 gives the root bean's own node, a nameless bean node, where earlier versions gave no node. supports() accepts the subclasses of the entity, so a subclass instance that is an entity of its own was validated with the rules of the superclass. validate() hands such an instance, unwrapped from a proxy, to the validator of its own entity, with the same hints and cascade flag. Retargeted to 9.0.x: the upgrade note moves to the Grails 9 notes and the @since tags say 9.0.0. Report URL: https://github.com/apache/grails-core/actions/runs/41066140740 With regards, GitHub Actions via GitBox
