-
v0.18.3 — event-day fixes: keep the photo, drop the broken camera
Some checks failedAudit / cargo audit (backend) (push) Failing after 9m31sAudit / npm audit (frontend) (push) Successful in 1m2sChecks / Backend — cargo test + clippy + fmt (push) Failing after 1m7sChecks / Frontend — vitest + svelte-check (push) Failing after 5m37sChecks / Keepsake viewer — builds, self-contained, committed artifact in sync (push) Failing after 5m13sChecks / E2E — typecheck + lint (push) Failing after 36sE2E / Playwright E2E (chromium + webkit) (push) Failing after 9m8sE2E / Cross-UA smoke matrix (push) Failing after 4m17sreleased this
2026-08-22 07:31:19 +00:00 | 4 commits to main since this releaseFrontend only. Backend unchanged since v0.18.0 and no migration touched (31), so
the app image is re-tagged and v0.18.2 remains a valid rollback target.- An unparseable 400 (axum's multipart rejection — what WhatsApp's iOS webview
produces when it truncates an upload) no longer counts as a permanent
rejection. It kept the blob out of IndexedDB and offered no retry, so a
transport hiccup destroyed the guest's only copy. Now retryable. - PUBLIC_CAMERA_ENABLED=false hides the in-app camera for events where
getUserMedia misbehaves on the guests' phones. Runtime variable on the
frontend service; the gallery picker still reaches the camera and video.
Downloads
- An unparseable 400 (axum's multipart rejection — what WhatsApp's iOS webview