An attachment that cannot be read says so instead of 500ing

FixMediaService
Ya
27 Agosti 2026, 07:03 UTC
Mwandishi
Kamo
Ahadi ya
9d70283

The imaging proxy already answers 410 for revoked access and for a removed message, but let openRange's IOException escape uncaught — so the one case where the bytes are simply absent became a blank 500. A browser's <audio>/<video> cannot render a 500; it gets one bit and latches on it, which is why a member reported an attachment that "sent" but whose play button did nothing, with no message anywhere. Three changes. The row is asked first: ImgDat.isMissing is false only once the bytes are durably written, so a missing row is answered 410 without a MinIO round trip at all. Storage failures are then split — ObjectNotStoredException to 410, anything else to 503 — so a MinIO blip reads as "try again" rather than as a file the member has permanently lost. And HEAD now actually consults storage. It used to answer 200 from the row's metadata, which made it worse than useless for the one question worth asking it: a client probing to learn whether a failed element is gone or merely unlucky was told the file was fine and then handed a 410 on the GET. A zero-length range costs one stat and settles it honestly. SystemBugController gets the same split. MediaController's outbound path already degraded to text, and now logs which of the two happened.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei