-
v0.18.6 — verify the copied bytes, so a mid-read purge cannot store a short file
Some checks failedAudit / cargo audit (backend) (push) Failing after 8m43sAudit / npm audit (frontend) (push) Successful in 42sChecks / Backend — cargo test + clippy + fmt (push) Failing after 1m7sChecks / Frontend — vitest + svelte-check (push) Failing after 5m35sChecks / E2E — typecheck + lint (push) Failing after 32sE2E / Playwright E2E (chromium + webkit) (push) Failing after 8m46sChecks / Keepsake viewer — builds, self-contained, committed artifact in sync (push) Failing after 5m4sE2E / Cross-UA smoke matrix (push) Failing after 4m55sreleased this
2026-08-22 16:08:48 +00:00 | 1 commits to main since this releaseFrontend only. Backend unchanged since v0.18.0, no migration touched (31), so the
app image is re-tagged and v0.18.5 remains a valid rollback target.v0.18.5 copies a picked file's bytes so IndexedDB owns data rather than a
reference iOS can delete. For a photo that is one arrayBuffer() and effectively
atomic; for a video it is a 4 MB-at-a-time loop over up to 500 MB, and the same
purge can land in the middle of it. The remaining slices then read as nothing,
new Blob builds a SHORT blob, and nothing notices — which is worse than the bug
it replaced, because an empty body is refused with a 400 while a short body
uploads, is stored, and leaves the guest with a truncated video that looks fine.The copy is now checked against file.size and a short read is refused at PICK
time, while the guest still has the file in front of them. addToQueue returns
'unreadable' instead of throwing so one bad file out of five does not abandon the
other four, and the composer names the file rather than counting it.Only files above the 4 MB chunk threshold can reach the partial case, so the
photo path v0.18.5 fixed is untouched.Downloads