borinquenkid opened a new pull request, #16070: URL: https://github.com/apache/grails-core/pull/16070
## Summary CI on #15972 (Neo4j GormRegistry migration) hit a failure in `OptimisticLockingSpec > Test optimistic locking` on a loaded `macos-latest` runner, consistently across all 3 matrix legs of that run. Investigation (see discussion on #15972) traced this to the test's own pre-existing timing sensitivity, not a regression from the GormRegistry/`Neo4jGormApiFactory` wiring: - The unmodified test passes locally, deterministically, against the exact commit that failed in CI — including correct `OptimisticLockingException` detection through the new registry-based API resolution. - The background thread's write is already synchronized with the main thread via `.join()` *before* the `sleep` runs, so the sleep isn't providing thread-completion synchronization — it's headroom for the embedded Neo4j 3.5.x test harness's own write durability. - The test's own code comment (`// heisenbug`) already flags this as a known flaky spot. A loaded CI runner can apparently push that durability window past the existing 2-second sleep. This PR bumps it to 5 seconds in both affected examples (`Test optimistic locking` and `Test optimistic locking disabled with 'version false'`) and documents why, rather than leaving the bare `// heisenbug` comment. ## Test plan - [x] `:grails-data-neo4j-core:test --tests "grails.gorm.tests.OptimisticLockingSpec"` — 3 tests, 0 failures (verified against both this branch's file and PR #15972's copy of the same file, which is otherwise unchanged content, just relocated by that PR's module restructuring) 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
