• v0.18.6 — verify the copied bytes, so a mid-read purge cannot store a short file
    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

    fabi released this 2026-08-22 16:08:48 +00:00 | 1 commits to main since this release

    Frontend 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