- Shipped
- September 6, 2026 at 9:22 PM UTC
- Author
- Kamo
- Commit
- 9ec79cd
Every attachment on a bug report rendered as a broken tile. In production: seven content requests, seven 401s, zero successes — while the report's own JSON loaded fine beside them. The difference is who issues the request. `<img>` and `<video>` are issued by the browser, and unlike every `fetch` in this app they cannot carry the per-tab `X-***-Token` header, so they authenticate on the *** cookie alone — and that cookie is only re-planted on user activity. A member who left the console idle therefore lost every attachment while the rest of the page kept working, which is exactly the failure `useAttachmentSource` was written for. The System Bugs gallery never used it: it drew a raw `<img src>` with no `onError`, so the element latched on its one bit of information and nothing anywhere said why. That hook is now shared rather than copied. It took an `objImgId` and built the imaging-proxy path itself, which is what kept it out of reach of a gallery served from a different endpoint; it takes a URL now, and its cache-buster appends with `&` when the caller's path already carries a query. Each tile is its own component so each owns its own re-plant and retry. Hoisting that state into the gallery would give ten tiles one verdict, and a single missing file would blank the other nine. A failure that survives the re-plant is drawn as a tile that says so — retryable by default, because a lapsed session is the commonest cause and telling somebody a file they just uploaded has vanished is the worse mistake. Only an explicit 410/404 earns the permanent wording. The lightbox gets the same treatment, in place of a full-screen broken-image glyph on black. Not a regression from the thread work — the raw `<img>` dates from c6923e43, the original screenshots-and-videos feature. The bug was reported alongside it and is older than it.