- Shipped
- 22 ஆகஸ்ட், 2026 அன்று 11:17 PM UTC
- Author
- Kamo
- Commit
- b31fb30
imgs_assoc_id_check allowed assoc_id 0..13. ImageAssocType.PICTURE_FRAME is ordinal 14, so EVERY Picture Frame upload violated it. Hibernate writes CHECK (col BETWEEN 0 AND N) for an @Enumerated(ORDINAL) column when it CREATES the table and never updates it again, so N is the enum's size on the day the table was made. Append a value and every insert carrying the new ordinal violates a constraint nobody remembers exists. The failure is unusually opaque because ImageService.uploadDocument is @Transactional: the violation rolls the whole method back, taking the Img row it had already written with it. So there is no failed-upload row, no partial state, and nothing in the database pointing at the cause — just a generic error. Diagnosing it meant ruling out the MIME gate, the extension whitelist, multipart limits and the proxy chain first. imgs_client_mime_check allowed 0..35 against an ImageMimeType that has exactly 36 values. Full. The next MIME type anyone added would have broken EVERY upload on the platform rather than one feature's, so it is dropped here too, along with the older hand-written check_client_mime (ceiling 99) and the sig_template_status check, which is equally full at 0..2. Dropped rather than widened, which is what **************** already does for the rights tables and for the same reason: @Enumerated enforces valid values in Java, so the database check is redundant, and widening only moves the bomb rather than defusing it. Already applied to production.