- Shipped
- August 11, 2026 at 6:36 PM UTC
- Author
- Kamo
- Commit
- b4fd867
Found by running it. YugabyteDB performs online schema change, so a CREATE UNIQUE INDEX issued while Hibernate's ddl-auto pass is still settling can lose the race and return 40001 "could not serialize access due to concurrent update". The statement is fine — the identical one succeeds moments later. Treating that as fatal was much worse than it sounds. This runner is @Order(43), so the throw aborted the entire initializer and skipped all 27 runners ordered after it. One transient conflict therefore silently withheld every later migration on the platform, and the only visible symptom was a stack trace in the middle of an otherwise normal run. ensureRequired and ensureCheckConstraint now retry up to five times with linear backoff when the failure is a concurrency conflict, matched on SQLSTATE 40001 and on the message (the driver surfaces it both ways depending on where it is raised) and walking the cause chain, because Spring wraps it. The match is deliberately narrow: a missing table, a bad column or a duplicate-key conflict on real data is a defect that must still fail loudly rather than be retried four more times and then fail anyway. Verified against the live database after the fix: all 20 hr_training_* tables present, all five required unique indexes created, the two-column course-item CHECK in place, all four training email templates seeded (one SYSTEM row plus 13 org rows each), and every runner after @Order(43) reached.