fabi
c8795ddfac
Some checks failed
Audit / cargo audit (backend) (push) Failing after 8m43s
Audit / npm audit (frontend) (push) Successful in 42s
Checks / Backend — cargo test + clippy + fmt (push) Failing after 1m7s
Checks / Frontend — vitest + svelte-check (push) Failing after 5m35s
Checks / E2E — typecheck + lint (push) Failing after 32s
E2E / Playwright E2E (chromium + webkit) (push) Failing after 8m46s
Checks / Keepsake viewer — builds, self-contained, committed artifact in sync (push) Failing after 5m4s
E2E / Cross-UA smoke matrix (push) Failing after 4m55s
v0.18.5 copies a picked file's bytes into a Blob the origin owns, because WebKit stores a `File` as a reference to an OS file that iOS later deletes. For a photo that is one `arrayBuffer()` and effectively atomic. For a video it is a 4 MB-at- a-time loop over as much as 500 MB, which takes many seconds -- and the purge that motivated the whole function can land in the MIDDLE of it. Once the OS file is gone the remaining slices read as nothing, `new Blob` builds a short blob out of what it got, and nothing notices. That is strictly worse than the bug it replaces: an empty body is refused with a 400, but a short body uploads, passes the server's checks, and leaves the guest with a truncated video that appears to have worked. Silent corruption beats loud failure only in the sense that nobody finds out until the album is the only copy left. So the copy is now checked against `file.size` and a short read is refused. It is raised at PICK time, while the guest still has the file in front of them and can select it again -- not at send time, minutes later, when the moment has passed. `addToQueue` returns 'unreadable' rather than throwing, so the composer's per-file loop survives it: one bad photo out of five must not abandon the other four. The composer names the file in the toast instead of counting it the way it counts 'full', because the guest has to locate and re-pick that specific one. Scope: only files above the 4 MB chunk threshold can hit the partial case, so this does not touch the photo path that v0.18.5 fixed. It closes the hole that fix opened for videos.