- Spegnimento
- 22 agosto 2026 alle ore 23:17 UTC
- Autore
- Kamo
- Impegno
- b31fb30
imgs assoc id check ha permesso assoc id 0...13. ImageAssocType.PICTURE FRAME è ordinal 14, così ogni foto frame upload ha violato. Hibernate scrive CHECK (col TRA 0 E N) per un @Enumerated (ORDINAL) colonna quando CREATES la tabella e non lo aggiorna mai più, quindi N è La dimensione di enum il giorno in cui il tavolo è stato fatto. Applicare un valore e ogni inserto portare il nuovo ordinale viola un vincolo che nessuno ricorda esiste. Il fallimento è insolitamente opaco perché ImageService.uploadDocument è @Transactional: la violazione rotola l'intero metodo indietro, prendendo la riga Img aveva già scritto con esso. Quindi non c'è nessuna riga di carico guasto, nessuna parziale stato, e nulla nel database che indica la causa — solo un generico errore. La diagnosi significava escludere il cancello MIME, l'estensione whitelist, i limiti multipart e la catena proxy prima. imgs client mime check ha permesso 0..35 contro un ImageMimeType che ha esattamente 36 valori. Pieno. Il prossimo tipo MIME che chiunque ha aggiunto avrebbe rotto OGNI caricare sulla piattaforma piuttosto che una caratteristica, quindi è caduto qui anche, insieme al vecchio check client mime scritto a mano (ceiling 99) e il sig template status check, che è ugualmente pieno a 0..2. E' caduto piuttosto che allargato, ed e' quello che e' successo. già fa per le tabelle dei diritti e per lo stesso motivo: @Enumerated applica i valori validi in Java, quindi il controllo del database è ridondante, e L'ampliamento muove solo la bomba, piuttosto che sfidarla. Già applicato alla produzione.