- Shipped
- September 5, 2026 at 12:19 AM UTC
- Author
- Kamo
- Commit
- 9b08a73
My own regression, and the second context-startup break on this service today: Error creating bean with name 'terminalTicketRegistry': Failed to instantiate [...TerminalTicketRegistry]: No default constructor found Caused by: **************** **************** Spring picks a constructor by itself ONLY when a class has exactly one. Given two and no @Autowired it falls back to the no-argument default. This class has carried two constructors for a long time — a public no-arg one and a package-private one taking a Clock for tests — and was fine, because the fallback found the no-arg. Moving the tickets into a shared store replaced that no-arg constructor with one taking a dependency, so there was nothing left to fall back to. Nothing caught it. It compiles. Every unit test passes, because they call the constructor directly and never exercise Spring's selection at all. And the guard that exists for exactly this shape, ApplicationContextStartsTest, is @Disabled until there is a Redis for it, while CI runs the suite with -DskipTests. So it comes with a ratchet, as the @Lazy break did. **************** reflects over every stereotype-annotated class and fails any bean with two or more constructors where none is @Autowired and there is no public no-arg fallback — which is precisely what Spring itself looks at. Verified red against the broken tree (it named this class and only this class, so nothing else in the service has the defect) and green after the fix. Full suite in an isolated worktree: 2175 tests, 0 failures.