- Shipped
- September 4, 2026 at 10:39 PM UTC
- Author
- Kamo
- Commit
- fe3e433
Every SecurityService pod built since 4bd25e7 fails to start: The dependencies of some of the beans in the application context form a cycle: ┌──->──┐ | commitLogTranslationListener (field ... .self) └──<-──┘ CommitLogTranslationListener injects itself so that translateCommitLog() is called through the Spring proxy — a @Async/@Transactional method invoked as this.method() bypasses the proxy and the annotation does nothing. What made that legal was @Lazy on the field. It is still in the file, and that is the whole trap: 4bd25e7 inserted the SingletonTaskRunner field between the annotation and the field it guarded, so @Lazy bound to the new neighbour instead. Nothing was deleted, the diff read as a pure addition, and the self-injection quietly became eager. It hid well. An older pod stayed up serving traffic while both new ReplicaSets CrashLooped, so the service looked healthy and merely stale — which is how it not answering", because the endpoint it calls only exists in the image that could not start. Nothing caught it and nothing could have. ApplicationContextStartsTest is the guard for exactly this failure mode and is @Disabled until there is a Redis for it, and CI here runs the suite with -DskipTests, so a red tree builds and deploys. So the fix comes with a static ratchet. SelfInjectionLazyRatchetTest reads the source and asserts that every field whose type is its own declaring class has @Lazy DIRECTLY above it — adjacency, not mere presence, since "the file contains an @Lazy somewhere" was true throughout the outage. It fails on the bug and passes on the fix, and it fails loudly if it ever stops finding self-injections at all, rather than passing vacuously the way SecurityServiceApplicationTests did for months. (Written first as one regex spanning the annotations, which backtracked into a StackOverflowError — a failure that looks exactly like a detection until you read it. It now matches a line at a time.) Full suite: 2130 tests, 0 failures.