An attachment that cannot be read says so, instead of nothing

Fixkamo-internal
Shipped
August 27, 2026 at 7:04 AM UTC
Author
kamo
Commit
8d02496

A media element gives you one bit — it failed — and no status code, and it latches on that bit: it never retries, so whatever went wrong the control simply stays dead. AttachmentChip assumed every failure was the known lapsed-*** 401, re-planted the cookie, reloaded once, and then swallowed the second failure. So an attachment whose bytes were never stored reached a member as a play button that did nothing and explained nothing. That is why the underlying upload defect took a second report to surface. The one-shot cookie replant is unchanged — it is still the likeliest cause. What is new is what happens after it: one HEAD buys the status the element cannot report, and the proxy's 410/503 split turns that into either "no longer available" or "couldn't load" with a button that can actually help. Only an explicit 410/404 earns the permanent wording; 401 and 403 stay retryable, because a lapsed session fixes itself and must never be reported to a member as a file they have lost. Extracted into a hook and one notice component so the chip, the lightbox and the download links share a single implementation rather than three that drift. Downloads are guarded on click — a plain file has no element to fail, so the click is the only moment we can find out, and it beats opening a tab full of the server's error body. Modifier-clicks fall through untouched so middle-click and "save link as" keep working. Strings landed in kamo-translation-dictionary first (8224520e).

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing