- Shipped
- September 8, 2026 at 7:39 AM UTC
- Author
- Kamo
- Commit
- 8875552
MediaService crash-looped on the Hold'em image. The six repositories shipped as nested interfaces inside one `HoldemRepositories` class — one file rather than six, so "what can be asked of a table" would live in one place — and Spring Data's scanner walks straight past a nested interface. Not one of the six beans existed: Parameter 0 of constructor in HoldemDeadlineSweep required a bean of type **************** that could not be found. Six top-level files now, each named `Holdem<Thing>Repository` so a second feature's `TableRepository` can never collide with one. **Nothing caught it, and that is the part worth fixing.** It compiled. All 35 unit tests passed. The query-parse test beside it compiled every hand-written @Query against the real entity model and still saw nothing, because it works by reflection and never boots a Spring context — which is what makes this service's suite fast, and what let this reach a pod. `HoldemRepositoryLayoutTest` closes it two ways: a source scan that fails the build on ANY indented interface extending a Spring Data repository anywhere in the service, and a reflective check that every Hold'em repository has no enclosing class. Both need no context and no database. No outage: the previous replicaset stayed healthy throughout and kept serving, so only the rollout was stuck.