- Shipped
- August 9, 2026 at 5:46 PM UTC
- Author
- kamo
- Commit
- e7b7bc9
A video arriving in a conversation could not be played until the page was reloaded, while a video the member had just sent always played. Both copies were byte-identical — re-sending the same file produced a working attachment pointing at the very same stored object — so it was never the file or the format. Media tags are issued by the browser, so unlike every fetch in the app they cannot carry the per-tab X-***-Token header and authenticate on the *** cookie alone. Verified against the live proxy: cookie-only 206, header-only 206, neither 401. That cookie is re-planted only on user activity, so a member sitting idle in a conversation loses it while the rest of the app carries on working from sessionStorage. A video that arrives right then gets a 401 on its first request — and an <img>/<video>/<audio> element LATCHES that failure. It never retries, so the control stays dead until a reload builds a fresh element. Sending is activity and keeps the cookie alive, which is why a member's own attachments were never affected. On error the element now re-plants the session cookie and reloads its source once. Once only: a second failure is real, and retrying at a dead session helps nobody. This is recovery, not prevention — media auth still rests on a cookie that can lapse while the tab's real session is alive.