- Spegnimento
- 26 agosto 2026 alle ore 02:33 UTC
- Autore
- kamo
- Impegno
- a04da73
Il softphone ha aperto la connessione SockJS/STOMP ai media. boot. getCapabilities() è atteso alcune righe sopra ed è la risposta del backend a "può questo org prendere chiamate", ma la presa è stata impostata fuori da quel cancello — così un membro un org senza sistema telefonico configurato ha aperto la connessione comunque, ha pagato il suo /info XHR, e poi tenuto aperto con una coppia battito cardiaco ogni 20 s, per scheda, per eventi che potrebbero Non arriva mai. Ora è dentro `se (caps?.voiceCalls)`. Deliberatamente il proprio blocco piuttosto che piegato nel cancello SIP-credentials sopra di esso: che uno presto torna quando il fetch credenziali fallisce, e un org con voce dovrebbe ancora ottenere la presa anche quando la registrazione potrebbe non essere stabilito. La sequenza di avvio ha anche preso /api/user-info direttamente, rendendolo il settimo indipendente chiamante di quel punto su un carico acuto freddo — ciascuno un Redis EXISTS + SETEX più un Ricomputo dei diritti di sicurezza. Passa attraverso loadUserInfoShared ora, il carboniere che già esisteva in useUserInfo, esportato per chiamanti al di fuori del gancio. Raggiungerlo da un effetto semplice piuttosto che consumare l'usoUserInfo() è deliberato: il gancio aggiungerebbe un altro intervallo di aggiornamento di 5 minuti e un altro ascoltatore di cambiamento di visibilità per una risposta softphone ha bisogno di una volta, al boot. Lo scambio risolve anche qualcosa di più tranquillo. Il fetch grezzo non ha mandato niente X-***-Token, quindi ha appoggiato sul biscotto piuttosto che nominare la sessione che tiene questo TAB; il caricatore condiviso legge La scheda e' proprio un segno. E quando non c'è sessione ora ritorna invece di portare avanti — il vecchio percorso ha trasformato un corpo 401 in String (non definito) e inizializzato un softphone per membro "non definito". Decisamente NON fatto: collassare le cinque connessioni STOMP su clienti condivisi. Tre. andare a un URL identico e due all'altro, quindi c'è rifiuti reali lì, ma il la notifica e le prese e-mail hanno materialmente diversi budget di riprovazione e il give-up politiche — la condivisione di loro farebbe notifiche rigorosamente meno resilienti per acquistare alcuni cornici. Ha bisogno di un registro di collegamento con la semantica per-subscriber, non una fusione. verificato: tsc --noEmit clean over useSoftphone, useUserInfo, SoftphoneContext e SoftphonePanel con le loro importazioni transitive; nessun ciclo di importazione introdotto; tutte le 9 guardie passare, compreso check-session-token-source; 29 voip e test di sessione passano.