- Spegnimento
- 5 settembre 2026 alle ore 18:53 UTC
- Autore
- Kamo
- Impegno
- 24ee442
Il catch-all alla fine del login() mettere e.getMessage() nel corpo di risposta, e quel corpo è reso verbatim sullo schermo del segnale. Il 2026-09-05 l'eccezione arrivare c'era un conflitto di conversione catalogo Yugabyte, quindi quello che un membro ha visto era SELECT generato da Hibernate: ogni colonna di depts, orgs e org mtg, la forma dei legami tra loro, e la tabella interna id — uno schema di scarico consegnato a qualcuno che è per definizione non ha ancora firmato. Non si perde nulla trattenendolo. Il tipo, il messaggio e la traccia completa dello stack sono già registrati immediatamente sopra, che è dove un fallimento a questo livello ottiene diagnosticato da; la persona che digita una password non può fare nulla con una dichiarazione SQL. La formulazione corrisponde al proprio fallback di kamo-login per questo caso, così lo schermo legge lo stesso se il messaggio è venuto da qui o il browser non ha mai ottenuto uno. Questa è la seconda metà della fissazione per quel rapporto, non la fissa stessa: la il conflitto che lo ha causato è ora retribuito in MemberRightsAppliedService. Questo è quello che lo schermo mostra se un guasto passa il retry comunque, ed è anche che cosa mostrerà per ogni altra eccezione che finisce qui. Lascia lo stesso modello in logout, /validate e il endpoint sessione-refresh da solo; nessuno di loro è apparso nella relazione e ognuno merita il proprio sguardo. Compili puliti; nessun test ha affermato il vecchio messaggio.