- Shipped
- September 23, 2026 at 11:28 AM UTC
- Author
- Kamo
- Commit
- 723ad95
d47b471's SessionAccessGuard field on WebSocketConfig crash-looped every pod: Spring must fully construct WebSocketConfig (a **************** every @Autowired field resolved) before it can build brokerMessagingTemplate and the rest of the broker infrastructure, which calls back into this same class's configureClientInboundChannel. SessionAccessGuard depends on SupportTicketService, whose own chain (SupportAssignmentService -> SupportNotificationService -> PushDispatchService -> PresenceService) needs a SimpMessagingTemplate - which in this app IS brokerMessagingTemplate. Confirmed live: every replica of the new build hit "brokerMessagingTemplate: Requested bean is currently in creation" and CrashLoopBackOff'd; the two still-running old-build pods kept serving throughout, so this was a stuck rollout, not an outage. sessionAccessGuard is now @Lazy, so the field holds a proxy during WebSocketConfig's own construction and the real bean - and its full dependency chain - only resolves on first use (the first live-session SUBSCRIBE), long after the broker has finished starting. Verified by redeploying and reading the new pod's own startup log rather than just its readiness state - this class of failure never touches a request path a unit test can reach, which is exactly why 1098 green tests didn't catch it the first time; only a real ApplicationContext refresh does.