- Shipped
- 23 settembre 2026 alle ore 11:28 UTC
- Author
- Kamo
- Commit
- 723ad95
campo SessionAccessGuard di d47b471 su WebSocketConfig crash-looped ogni pod: La primavera deve costruire completamente WebSocketConfig (a Non e' vero. ogni campo @Autowired risolto) prima di esso può costruire brokerMessagingTemplate e il resto del broker infrastrutture, che richiamano a questa stessa classe configurareClientInboundChannel. SessionAccessGuard dipende da SupportoTicketService, la cui catena (SupportAssignmentService -> SupportoNotificationService -> PushDispatchService -> PresenceService a SimpMessagingTemplate - che in questa applicazione è brokerMessagingTemplate. Confermato dal vivo: ogni replica della nuova costruzione ha colpito "brokerMessagingTemplate: Il fagiolo richiesto è attualmente in creazione" e CrashLoopBackOff'd; i due ancora-running vecchi-costruire pods continuato a servire in tutto, quindi questo era un bloccato non un'estrazione. sessionAccessGuard è ora @Lazy, quindi il campo detiene un proxy durante WebSocketCostruzione propria e il fagiolo reale - e la sua completa catena di dipendenza - si risolve solo sul primo uso (la prima sessione di vita SUBSCRIBE), molto dopo che il broker ha finito di iniziare. Verificato da ridicolizzare e leggere il registro di avvio del nuovo pod piuttosto che solo il suo stato di prontezza - questa classe di fallimento non tocca mai un percorso di richiesta un'unità test può raggiungere, che è esattamente il motivo per cui 1098 test verdi non ha preso esso la prima volta; solo un vero e proprio ApplicationContext rinfresca lo fa.