87 Commits

Author	SHA1	Message	Date
MechaCat02	5b705317ef	fix: close the last three guest-facing dead ends (items 7-9) ... C1 — a failed page-append silently ended infinite scroll `loadMore`'s catch showed a toast and changed no state, unlike every sibling error path in the file. `nextCursor` survived so the feed was still technically paginable, but the IntersectionObserver only fires on a CHANGE: after a failed append nothing scrolls and no rows are added, so it never re-fires. One 429 or wifi blip and the guest concluded the gallery was 20 photos. Now leaves a retry control at the sentinel — a toast that fades in 5s is not an affordance — resuming from the untouched cursor. C2 — the export page reported downloads that never happened `downloadFile` toasted 'Download gestartet' the instant it assigned the iframe's src, before a single byte existed. Since the iframe swallows errors BY DESIGN (a top-level navigation to a 404 would unload the PWA), a failure produced a green success message, a consumed single-use ticket, and one of only three daily slots spent — repeatable until the day's allowance was gone, on the screen that is the whole point of the app. Root cause is two sources of truth: `export_status` reports `done` from `export_job` and enables the button, while the download resolves through `export_current.file_path` plus a `Path::exists()`. They can legitimately disagree. `export_ticket` now takes a `kind` and calls the existing `resolve_export_file` BEFORE charging the rate slot, so a missing archive fails honestly on a plain fetch that `toastError` already renders. Not the HEAD probe ruled out elsewhere: it reads the same indexed row the download will read and touches no ticket, so it cannot consume anything. The parameter is optional, so an older client degrades to today's behaviour rather than breaking. C3 — the WhatsApp journey could dead-end with no error at all The join link travels through guest group chats, and a link tapped inside one opens in that app's browser, where the file picker and getUserMedia both depend on the host app having wired them up. When they aren't, the buttons do nothing — no error, nothing to act on. Two targeted changes rather than a UI rebuild: the camera error panel now offers "Aus Galerie wählen" (its advice to change "Browsereinstellungen" refers to settings that do not exist in a webview, so retrying could never help those guests), and the sheet carries a standing one-line hint to open the link in Safari or Chrome. Deliberately no user-agent sniffing: a sniff list is wrong for every browser it has not heard of, while a quiet standing hint costs one line and is never wrong. The hint lives in UploadSheet rather than the root layout because both layout banners are gated on `$showBottomNav`, which `/upload` turns off — one there would never render on the composer. Verified: 151/151 backend tests against a live Postgres, clippy clean, 58/58 vitest, svelte-check 0 errors, eslint clean, both builds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-08 22:38:07 +02:00
MechaCat02	05063694d2	fix: close eight regressions the audit pass found, five of them mine ... Two adversarial reviews over 61119be, 1d9fb11 and eb0e405. The merge itself came back clean — client_upload_id end to end, TempFileGuard's arm/retarget/disarm, the supervised sweep wiring and v_feed's column parity were all verified sound. What follows is what my own three commits broke. BLOCKER — a post-release rebuild was permanently impossible, and it 404'd the keepsake 1d9fb11 deferred prune_superseded_archives to run only on success, so a failed rebuild could no longer destroy the last good archive. It did not follow that through: ensure_export_space runs BEFORE the prune, so at rebuild time the previous generation is still on disk and counted against free. That halves the gallery a rebuild can survive (~4.6 GB) relative to what the upload gate accepts (~7.8 GB) — and it self-locks, because invalidate_and_arm bumps the epoch on COMMIT, which 404s both download routes immediately, while the only code that could free the space now runs only after a success that can never happen. A guest deleting their own photo is enough to trigger it. Recovery needed `docker exec rm`. Now two-phase: try to build while preserving the old generation; if that genuinely does not fit, reclaim it and try once more. Strictly better than both the original ordering and my change — the old archive is sacrificed only when it is the only way to get a new one. BLOCKER — the deferred prune could delete the last archive when a worker LOST the race run_*_export_inner returned Ok(()) on the superseded/discard path, so `res.is_ok()` fired the prune with the worker's own RETIRED epoch as keep_seq. At that moment the winning generation is still `pending` with no file, so protected_files is empty and the last good archive was deleted with no replacement. Exactly the invariant deferring the prune was meant to establish. Returns Err(Superseded) now, which abandon_if_superseded already swallows for the caller. BLOCKER — the low-disk banner could never fire before the wall eb0e405's gate refuses at `free < keepsake + DISK_RESERVE`, while disk_is_low warned at `free < keepsake`. The two differ by the whole reserve, so the wall always came first: every guest blocked from uploading while the host dashboard showed ~27 GB free and no banner, with nobody on site. disk_is_low now shares the gate's expression plus a 25% margin, and a test asserts the banner fires at the gate threshold across the whole gallery-size range. BLOCKER — I raised the unauthenticated bcrypt ceiling 24x on a 2 vCPU box 1d9fb11 moved admin_login's tight bucket after verify_password (correct — that is what stops a guest locking the operator out) but replaced the incidental 5/min bound on bcrypt with 120/min and nothing global. bcrypt is on spawn_blocking, but tokio's blocking pool is 512 threads, so "off the runtime" is not "bounded": enough concurrent verifies preempt both async workers and uploads, feed and SSE stall. Three unauthenticated endpoints reach bcrypt and every guest shares one NAT IP, so per-IP limits bound nothing globally. Adds a process-wide semaphore of `cores - 1` around both verify and hash, and drops the ceiling to 30. Also correcting my own claim: "a correct password is never throttled" was wrong. The failure bucket cannot block it, but the CPU ceiling still can. The code comment said so; the commit message did not. BLOCKER — migration 025 could crash-loop the app on boot Its UPDATE derives `Name (8hex)` with no guard against idx_user_event_name_ci. A guest who had already joined as exactly that string makes the migration fail, which propagates out of create_pool, exits main, and `restart: unless-stopped` turns it into a permanent loop — a worse version of the lockout the migration exists to clean up. Now skips colliding rows (create_admin_user already falls back to Admin-<8hex>, so the cleanup is convenience, not load-bearing). Also `role = 'guest'` rather than `<> 'admin'`, which was renaming legitimately promoted hosts named "Host". DEGRADATION — the watchdog's suspension credit was unbounded Background tabs are throttled to ~1 tick/min WITHOUT the network stack pausing, and the tick gap cannot tell that from a freeze. Crediting every late tick grew the observed silence by only one interval per real minute, so a dead socket took ~18 minutes to detect while holding the queue's processing latch. Credit is now capped at one stall window and REFILLS on real progress: an upload that is moving survives any number of screen locks, while one that is silent and suspended is detected within ~3 minutes. DEGRADATION — the 4xx log line was an unauthenticated log-injection vector validate_display_name allowed newlines, several 4xx messages interpolate the name, and %message wrote it unescaped. Two unauthenticated /join requests could forge arbitrary lines in the only forensic record an unattended event has. Fixed at both ends: control characters rejected at the door, and `detail = ?message` escapes on the way out (which also stops colliding with tracing's reserved `message` field). 401/404 drop to DEBUG — they carry no operator signal and were the cheapest lines for a scanner to use to roll the 30 MB log window in minutes. DEGRADATION — the quota floor was inverted exactly where it mattered `computed.max(MIN.min(budget))`: `budget` is the whole disk's share, so below 500 MiB the "floor" became the entire remaining budget and EVERY uploader was authorised all of it — 400 MB free, 3 uploaders, 300 MB each. A test pinned that as correct under the name `the_floor_never_exceeds_what_the_disk_can_back`. Both fixed. Also replaces the headline gate test, which asserted its own precondition inside an `if` on that precondition and could not fail. It now pins what actually binds the gate to the preflight — that required_free_bytes charges for both halves — plus the ceiling band. Verified: 151/151 backend tests against a live Postgres, clippy clean, 58/58 vitest, svelte-check 0 errors, eslint clean, both builds, caddy validate, and the migration collision reproduced against Postgres 16 before and after. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-08 22:33:43 +02:00
MechaCat02	eb0e405562	fix: gate uploads on keepsake headroom, and close five unattended-event gaps ... The box is 2 vCPU / 4 GB / 40 GB, not the 4 vCPU / 8 GB / 80 GB that the audit, the committed comments and README's sizing section all assumed. That correction is what the first change is about; the rest are the remaining pre-event items. THE ARCHIVE COULD BECOME UNBUILDABLE WHILE UPLOADS KEPT SUCCEEDING `required_free_bytes` is `media × 1.1 × 2` — the ZIP and the HTML viewer are each gallery-sized — and the export preflight also wants DISK_RESERVE_BYTES on top. The upload gate, though, only refused below a FLAT 10 GB reserve. On 40 GB that let uploads run to ~25 GB of media while a release needed `2.2 × 25 + 10` = 65 GB free. Every upload in that band succeeded and the keepsake could then never be built: the product's entire promise, failing silently at the end of the night with nobody there. The gate now enforces the invariant that actually matters — never accept an upload that would make the keepsake unbuildable — sharing `required_free_bytes` with the preflight so the two cannot drift into disagreeing about the same question. Uploads stop at ~8 GB of media on this disk, with a German message naming the cause. Refusing the 1001st photo beats losing all 1000. `media_total.rs` backs it: SUM(user.total_upload_bytes) over ~100 rows, cached 5s, rather than `estimate_export_bytes`'s join across every upload. It counts hidden and banned users' bytes, which the export excludes — skew in the SAFE direction, so the gate closes marginally early rather than late. Fails open on a query error. A test pins the gate against the preflight across the whole gallery-size range, and a second asserts the per-user floor alone would over-commit the volume — i.e. that the global gate is what must bind. THE WATCHDOG ABORTED HEALTHY UPLOADS EVERY TIME A PHONE WAS POCKETED `Date.now()` advances while a backgrounded phone is frozen but `setInterval` does not, so the first tick after a screen lock read the whole sleep as silence and aborted — re-sending a video from byte zero and burning one of five PERMANENT auto-attempts. The interval is now its own suspension detector: a tick that arrives 125s late for a 5s schedule credits that window back, because a period the watchdog could not observe is not evidence of silence. Chosen over a `visibilitychange` listener, which only covers causes that fire that event — a throttled-but-visible tab, a closed lid and an occluded window all freeze timers without one — and which would have needed module state, an SSR guard and a teardown for strictly less coverage. `performance.now()` was rejected because Safari pauses it across system sleep on some paths and Chrome does not. The credit buys one fresh window, not immunity: a socket iOS reaped while backgrounded still aborts ~90s after resume rather than hanging for `xhr.timeout` (5-60 min) with the queue's `processing` latch held. Two latent leaks found while in there: `xhr.abort()` on a request already in readyState DONE emits no `abort` event, so `settle()` never ran and the interval re-aborted every 5s forever while `activeUploads` kept a stale entry (the ✕ button silently stopped working); and a synchronous throw from `xhr.send` — a blob whose backing store the OS purged — leaked the same way. Both closed. OKLCH MADE THE DELETE BUTTON INVISIBLE ON SAMSUNG'S DEFAULT BROWSER red/amber/green were never in the @theme block and fell through to Tailwind v4's `oklch()` defaults, which Safari <15.4, Chrome <111 and Samsung Internet <22 cannot parse: `var(--color-red-600)` is then invalid at computed-value time, `background-color` falls back to transparent, and `.btn-danger` renders white text on nothing. Pinned to Tailwind's own defaults gamut-mapped to sRGB by Lightning CSS — the converter already in this pipeline — so modern browsers render exactly what they render today. Verified against seven hex fallbacks it had already emitted for the /alpha forms. rose and teal (avatar chips) had the same leak. The app CSS goes from 40 oklch declarations to 0. Also fixes `--color-purple-950`, which was simply missing: `dark:bg-purple-950/50` on the host dashboard was rendering default violet on EVERY browser, off-brand. The keepsake viewer only picks this up on a rebuild, so its committed artefact is rebuilt here too — still single-file, still zero external references. A BRICKED BOOT LOOKED LIKE A SPINNER FOREVER With `ssr = false` the page is empty until the bundle mounts, so a chunk 404 after a redeploy or a dead uplink left the guest on the boot spinner with no message, no reload control, and in a standalone PWA no URL bar. A 15s timeout in the existing nonce'd IIFE (no CSP change) swaps in German copy and a reload button. Deliberately a timeout rather than feature detection: a SyntaxError in the bundle is invisible to any capability check. Plus a <noscript>, since there was nothing at all to see without JS. EVERY 4xx WAS INVISIBLE AT ANY LOG LEVEL tower_http counts 4xx as a success, so it logs at DEBUG while production runs at info. If guests spend the evening hitting 429s or 413s, the post-event logs said nothing. Now one WARN per client error; 5xx excluded because Internal already logs its source chain and the pool-exhaustion 503 logs at construction. A DEAD FRONTEND SERVED A BLANK 502 `handle_errors 5xx` with an inline German page (the caddy service mounts only the Caddyfile, so there is no volume to ship a static file through). Verified empirically against this config, not from documentation: an upstream 404 through `reverse_proxy` still arrives as untouched `application/json`, and only a dial failure renders the page. That mattered — the keepsake download navigates a hidden iframe and DEPENDS on a real 404/429 arriving, and swallowing those would have been worse than the blank 502. CONFIG CORRECTIONS FOR THE REAL HARDWARE DATABASE_MAX_CONNECTIONS 30 → 15: sized to 2 vCPU rather than to the guest count. Since migration 024 a feed page costs well under a millisecond, so connections are no longer spent waiting, and 30 backends crowd the db container's 1 GB on a 4 GB host. COMPRESSION_WORKER_CONCURRENCY stays at 2 — the merged heavy-image permit already serialises anything over 150 MiB, so the "two 48 MP photos" worst case that number was sized against is unreachable; dropping to 1 would halve light-path throughput and push more feed tiles onto full-size originals. README's sizing section rewritten for the actual disk. Verified: 149/149 backend tests against a live Postgres, clippy clean, 57/57 vitest, svelte-check 0 errors, eslint clean, vite build, export-viewer rebuild, caddy validate, compose YAML parse. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-08 22:07:56 +02:00
MechaCat02	1d9fb11c7b	fix: close the nine ways an unattended event loses photos or dies ... Every one of these was found in the pre-event audit, verified against source, and survives to production on the current main. Grouped by what actually goes wrong. PHOTOS DISAPPEAR * compression.rs no longer soft-deletes on a failed derivative. The guest got a 201, watched the card appear, then watched it vanish — the row left v_feed, find_visible_media and BOTH keepsakes, while its bytes sat on disk for 14 days waiting for a cleanup nothing announced. No screen anywhere lists compression failures, so recovery meant hand-written SQL that also had to re-add the refunded quota. Now it does exactly what the ENOSPC arm beside it already did and documented as correct: keep the row, serve the original, retry on the next boot (bounded by derivative_attempts). `upload-deleted` is no longer emitted; `upload-processed` is, so the card re-renders instead of sitting on a placeholder. * A 413 is now a reversible lock, so the blob survives. The quota moves — free disk falls, uploader count rises — so a guest goes over it having done nothing, and treating that as permanent meant a 400 MB video was pushed across cellular in full and THEN deleted from IndexedDB. Gone on both sides, and unrecoverable for an in-app camera capture that exists nowhere else. * quota_limit_bytes gained a floor and a stable divisor. The ceiling used to decrease monotonically all evening; it now settles at max(uploaders, estimated_guest_count) — a config key that was seeded, validated in the admin whitelist, and read by no code at all. The floor is clamped to what the disk can actually back, so a full volume still yields zero rather than handing out an allowance it cannot honour. * Because that floor gives up the aggregate guarantee the formula used to imply, uploads now check a hard 10 GB reserve first, independent of every quota toggle. postgres_data, media_data and exports_data share one filesystem: the end state was not a degraded feature, it was Postgres unable to write WAL. THE ARCHIVE DISAPPEARS * prune_superseded_archives runs only after the new generation lands. It ran before the preflight, reasoning the old archive was already unreachable — true of reachability, false of recoverability. An epoch is a value that can be rolled back; deleted bytes cannot. Any failed rebuild left the event with NO keepsake at all. * The export preflight reserves the same 10 GB. `free < needed` authorised an export sized at exactly free, which ran for half an hour and landed the box at zero with the keepsake still unfinished. THE APP DIES * The feed reconcile re-reads the id set after its awaits instead of reusing one captured up to three round-trips earlier. The new-upload SSE handler prepends during exactly that window, so the row was both already present and absent from the stale set — prepended twice, and a duplicate key in a keyed {#each} throws in production, not just dev. The SSE handler and loadMore now dedupe too. * Added routes/+error.svelte. Without it any uncaught error fell through to SvelteKit's unstyled English 500 with no reload control — inside a chromeless standalone PWA with no URL bar, for the rest of the evening. THE OPERATOR IS LOCKED OUT * admin_login verifies the password BEFORE charging the rate bucket, and a correct password is never throttled. The old order made this a denial of service against its own operator: every guest shares one NAT IP, the check ran first, so five requests a minute from any phone in the room kept the bucket full — and the escape hatch needed the admin session being blocked. A generous separate ceiling still bounds bcrypt CPU. THE PROJECTOR DIES * The preload budget is now strictly inside the dwell. At the 3s option the 4s budget could never land a commit on a slow uplink, so the wall froze on one photo while the queue drained silently behind it. * The wake lock retries every 30s while visible, and the page says so on screen when the browser has no wake lock API. visibilitychange was the only retry trigger and a kiosk never changes visibility, so one refusal — iOS in Low Power Mode, say — was permanent. * Caddy: /api/v1/upload/*/display joins the cacheable carve-out. The backend set max-age=300 on it and the blanket no-store silently replaced it, so a projector re-fetched a full-size JPEG per slide, ~2-4 GB over an evening on the uplink the guests are uploading over. Also removes Upload::soft_delete, now unreferenced and an unscoped footgun next to soft_delete_in_event. Verified: 146/146 backend tests against a live Postgres, clippy clean, 51/51 vitest, svelte-check 0 errors, eslint clean, vite build, caddy validate, compose YAML parse. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-08 21:32:52 +02:00
MechaCat02	61119be817	Merge branch 'fix/deploy-unattended-blockers' into main ... Two independent lines of production hardening diverged at 7d0334b and attacked overlapping problems. Neither was a superset, so this is a merge of substance rather than a fast-forward: every conflict was resolved on the merits, and the losing side's intent was re-checked against the winner rather than assumed. MIGRATIONS. The branch's 021/022/023 collided with main's already-DEPLOYED 021_hashtag_counts_respect_bans and 022_client_upload_idempotency. Renumbered to 023/024/025 in a prior commit — main's versions are applied in production, so their version numbers are immutable and the branch's had to move. Verified by running the full sqlx::test suite, which applies the whole chain from scratch. RESOLVED IN MAIN'S FAVOUR (the branch would have regressed these): * upload-queue.ts wholesale — the branch's copy has ZERO client_upload_id references, so taking it would have silently destroyed end-to-end upload idempotency, the one thing standing between a lost response and a duplicate photo charged twice against the guest's quota. * maintenance.rs supervisor — the branch replaced it with a bare tokio::spawn, where one panic silently stops session pruning, media reclaim, the temp sweep and both HashMap prunes, permanently and with no log line. * The decode-budget probe on spawn_blocking, not inline on the async runtime. * feed/+page.svelte's 8s debounce + jitter + max-wait + hidden-tab deferral, against the branch's naive 800ms — at 100 guests the branch's version walks straight into the per-user feed rate limit. * db.rs pool tuning, /uploaders, and the docker-compose deployment story. * ONE /health, still DB-backed. The branch's split (dependency-free liveness + DB-backed readiness) is defensible, but a constant-"ok" /health is the exact defect faea555 fixed and verified live, its motive (Caddy's boot gate) is already covered by app depends_on db: service_healthy, and the two handlers were the same SELECT 1 under two names. TAKEN FROM THE BRANCH: * The large-PNG OOM guard and its bounded-retry counter (023). Together these turn a single upload that can OOM-kill a 1G container into a bounded failure instead of an infinite restart loop under `restart: unless-stopped`. * 024_feed_scalar_counts — the feed no longer aggregates the whole event per page. Pure SQL; column names, order and types are unchanged by design. * The admin-lockout fix: look the admin up BY ROLE, never by name. 025 also frees any guest already squatting on a reserved name. * PIN lockout tier ordering, bounded caption/hashtag reads, SSE ticket caps, PoolTimedOut -> 503 + Retry-After, and the ffmpeg stderr drain. * backfill_video_posters, which main lacked entirely. * TempFileGuard, plus sweep_orphan_originals wired into main's SUPERVISED loop (not the branch's bare one) — it reclaims final-named originals whose commit never happened, a class main's .tmp-only sweep structurally cannot see. * shouldAbortForStall, hand-ported into main's upload-queue.ts since that file was resolved to main. Widens the watchdog at loadend instead of disarming it, bounding a half-open socket at 2 minutes rather than handing the window to xhr.timeout (5-60 min) with the whole queue's `processing` latch held. ALSO: RUST_LOG and EXPORT_PATH pinned in compose. The code fallback was `debug` (a line per request, all night) and EXPORT_PATH was the one path with a mount-shaped default that nothing validated. Verified: cargo check --all-targets, cargo clippy (clean), 144/144 backend tests against a live Postgres including upload_idempotency and upload_concurrency, 51/51 vitest, svelte-check 0 errors, eslint clean, vite build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-08 21:16:31 +02:00
Fabian Hamm (Privat)	d5b4bf0ac1	fix(camera): get the upload sheet out from in front of the shutter button ... Tapping "Kamera" opened the viewfinder with the Galerie/Kamera sheet still sitting over the bottom of it, covering the capture controls. The sheet is `fixed`, so it could not be scrolled out of the way: the only route to the shutter was the phone's back button, which is not a discoverable step and is one most guests would read as "the camera is broken". Two independent causes, both fixed, because either one alone leaves a gap. The sheet never closed. It stays mounted for its translate-y animation and nothing told it the camera had taken over, so it kept its panel, its backdrop and its `aria-modal` while a full-screen overlay was up. `CameraCapture` now reports when its preview is live and the sheet dismisses itself on that signal. Deliberately on the preview, not on the tap. Closing when "Kamera" is pressed would dismiss the sheet before we know the camera works at all — and it often does not: a denied permission, no camera, or any non-secure context (where `navigator.mediaDevices` is simply absent) all end at the error panel. Closing early would leave the guest looking at that error with nothing behind it. Gated on `loadedmetadata`, the sheet is still there when the camera fails, so "Schließen" returns them to where they were. The signal is one-shot, because flipping the lens or switching photo/video re-acquires the stream and re-announcing "ready" would ask the caller to redo a dismissal it has already done. And the stacking was ambiguous. Both elements were `z-50` and the sheet is rendered after the camera, so it won on paint order. The overlay moves to `z-[60]` — the tier the Toaster already occupies, so toasts still surface above the viewfinder on DOM order. This is the part that holds regardless of timing: the controls are now reachable during the permission prompt and on the error panel, before anything has been dismissed. Focus follows the same reasoning. When the camera closes the sheet, restoring focus immediately would put it on the FAB *behind* the overlay, where a Tab could walk the page underneath; it is restored when the overlay goes away instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-04 19:38:49 +02:00
Fabian Hamm (Privat)	edc5f1f62c	chore(export-viewer): rebuild the embedded bundle, and fix the lint ignores ... The offline keepsake viewer had the same two filter defects as the app: typed suggestions were capped so a matching tag could be unselectable, and the dropdown used `onmousedown` with a backdrop that swallowed the selection. Rebuilt into `backend/static/export-viewer/index.html`, which `include_dir!` embeds in the binary. The eslint ignores were unanchored, so once the export-viewer's dependencies were installed its nested `.svelte-kit` output was linted as source. Anchored with `**/`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 18:37:09 +02:00
Fabian Hamm (Privat)	2b1500e624	fix(ui): make the dashboards agree with each other and with what the code does ... Host and admin implement the same four operations with independently written copy, and admin was stale or wrong in every case. Its release button was always enabled and always read "Galerie freigeben", so a second tap returned a 409; it showed no release state, no keepsake progress, no failure reason, no rebuild, and never refreshed after releasing. It now matches the host page. Both dashboards subscribed to SSE and never opened the connection — `onSseEvent` only registers a handler. Every subscription was inert, so the keepsake progress bar sat frozen after a release and PIN requests appeared only on a manual refresh. It happened to work when arriving straight from /feed, which connects, and /feed disconnects on destroy, so navigating to the dashboard killed it again. The unban confirm named neither of the two things a host most needs to know: unbanning also restores ALL of that guest's previously hidden photos to the gallery, diashow and export, and it retires and rebuilds a released keepsake, during which every guest's download is briefly unavailable. The ban modal warns that uploads vanish; nothing said they come back. Both now do, gated on the gallery actually being released. "Event verlassen" implied the account was being deleted, then the dialog said the guest could log back in. It calls `DELETE /session` — this device only, nothing deleted — so it is "Abmelden" now. Gallery release now states it locks uploads and is reversible; PIN reset states the guest is signed out on all devices. The keepsake download failed silently: nothing inspected the iframe result and the ticket POST always succeeded, so an over-limit tap did nothing at all. It now surfaces the (newly visible) 429 and confirms the download started. `/export` rendered "Export noch nicht verfügbar / Schau nach der Veranstaltung noch einmal vorbei" when the status request had merely FAILED — telling a guest to come back after an event that already happened. Both dashboards' error states gained a retry, which a host on a PWA with no URL bar otherwise has no way to reach. Modals were centred with no max-height, so on a short viewport the join PIN dialog clipped equally top and bottom — potentially putting "Weiter zur Galerie" off-screen at the moment a first-time guest must proceed. The ten moderation buttons were ~28px tall side by side, on the screen where a mis-tap bans the wrong guest; they are 44px now. Six German quotation marks paired the opening „ with an ASCII straight quote. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 18:36:57 +02:00
Fabian Hamm (Privat)	89ca819529	fix(diashow): never project a video, however its poster turned out ... `merge` decided by whether a usable still existed, so the same clip was included or dropped depending on whether ffmpeg happened to extract a poster — a video WITH a thumbnail was queued and shown as a frozen frame, one without was skipped. Keyed on the mime type instead: the projector shows stills only. The test factory casts through `as unknown as FeedUpload`, so adding a field the queue reads does not fail typechecking — it fails at runtime, which is how this surfaced as ten broken tests rather than a compile error. The factory now carries `mime_type` and the comment says why keeping it in step matters. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 18:36:57 +02:00
Fabian Hamm (Privat)	fffa2d556c	fix(upload): stop the queue from wedging, and tell the guest when it fails ... A STALLED UPLOAD BLOCKED EVERYTHING, FOREVER. The XHR set no timeout and had no stall detection, so a half-open connection from an AP roam left the item `uploading` indefinitely — which kept `processQueue`'s `processing` flag set, so the whole rest of the queue stopped draining. The UI offered no control at all for an `uploading` item. The guest saw "Wird hochgeladen 43%" all evening with four photos stuck behind it and no button to press; the only escape was force-quitting the PWA, which nobody guesses. Now: a watchdog aborts when no bytes move for 90s, disarmed on `loadend` so the server may take its time storing a file it already has; a size-scaled timeout as a generous backstop that will not kill slow-but-progressing LTE; and a cancel button. FAILURES WERE INVISIBLE. `handleSubmit` navigates to /feed immediately, and the queue component is mounted only on /upload — so a 5xx, a captive-portal error or an uploads-locked 403 wrote a German message into an item that nothing ever rendered. The guest believed the photo was uploading; it never appeared. Same for the documented rate-limit countdown banner, which lives in that same unreachable component and is now also rendered from the layout. RETRIES WERE UNCAPPED. `requeueRetriable` flipped every errored item back to pending on the `online` event AND on every `feed-delta` — i.e. every SSE reconnect — with no attempt counter and no backoff. On a flapping network a large failing video was re-uploaded from byte zero all evening, saturating the AP for everyone. Now a persisted attempt count, exponential backoff and a cap of five. INDEXEDDB COULD STRAND THE COMPOSER. `openDB` had no `blocked` handler, so a second tab holding an older version made it never settle, and it rejects outright on iOS private mode; `handleSubmit` had no try/catch and never reset `submitting`, so both buttons stayed disabled reading "Wird hochgeladen…" permanently, with no error and nothing queued. There is now a `blocked` handler plus a settle timeout, an in-memory fallback so uploading still works when persistence is unavailable, and a `finally`. A 401 during a background upload cleared the session without redirecting — and api.ts documents exactly why that strands a guest: the nav and FAB are gated on `isAuthenticated` so they vanish, route guards only run on mount, and a standalone PWA has no URL bar. Three early-return paths wrote status only to memory and never to IndexedDB, leaving blob-less error rows that could never be evicted and held the red FAB badge lit all night. A banned guest was offered the entire upload flow — FAB, camera, staging — and only the POST 403'd, while the new read-only banner told them uploading was disabled. The sheet now consults the ban, the layout subscribes to `user-hidden` so a live ban reaches the UI instead of arriving as a stream of 403 toasts, and the banner clears `env(safe-area-inset-bottom)` so the bottom nav stops covering it on notched iPhones. The /upload submit bar gets the same inset — it sat in the home-indicator zone, where the system swallows the first tap. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 18:36:30 +02:00
Fabian Hamm (Privat)	51e55b1ace	fix(feed): survive a bad network, and let the lightbox actually browse ... Four things a guest on congested venue wifi would have hit, and one they would have hit immediately. A FAILED FEED LOAD CLAIMED THE GALLERY WAS EMPTY. `loadFeed` caught, toasted for five seconds and left `uploads` empty, so the page fell through to "Noch keine Fotos. Tippe auf den Kamera-Button unten!" — the most likely first impression at the party, and a lie. There is now a distinct error state with "Erneut laden". Refreshes suppressed the toast entirely, so pull-to-refresh and the "Neue Beiträge" pill failed in total silence; they now report, and the pill survives its own failure instead of clearing before the request. THE FILTER-EMPTY STATE WAS DEAD CODE. With filtering server-side `displayUploads` is a plain alias of `uploads`, so the grid's "Keine Treffer für die gewählten Filter." plus its reset button sat behind an identical earlier branch and could never render — a guest tapping a chip with no matches was told to go take a photo. SSE COULD FREEZE THE FEED FOR THE WHOLE EVENING. Nothing in the feed ever refetched on a timer; every update path was triggered exclusively by a stream event. Behind a proxy that buffers `text/event-stream` `onopen` never fires, so the guest saw only the photos that were on screen when they arrived; and a socket left half-open by an AP roam is worse, because `connectSse` early-returns on a non-null EventSource and nothing ever reconnects. A pure silence timer is not implementable — the backend sends keep-alives as SSE comments, which the EventSource parser discards without dispatching — so liveness is established on evidence instead: a jittered 60-120s `/feed/delta` backstop that reconnects when a poll returns content the stream never delivered. The ticket round-trip also seeds the delta cursor before the EventSource is created, so the backstop has a `since` even if `onopen` never fires. THE PILL COLLAPSED A DEEPLY-SCROLLED FEED to 20 items and dumped the guest at an arbitrary scroll position — the exact yank the pill exists to avoid. It merges now. The refresh debounce was 800ms + jitter, which during a burst is roughly one feed query per client every two seconds; at 100 guests that approaches the 60/min per-user limit, and the resulting 429s were swallowed by a bare `catch {}`, so the feed would simply stop updating with no signal. Now 8s + jitter, coalescing, and skipped entirely while the page is hidden. Not one `<img>` in the app had an `onerror`. `pickMediaUrl` falls back to the original whenever preview and thumbnail are null — i.e. for everything still compressing, which during a burst is the top of the feed — so a 404 there rendered an empty grey box with `alt=""`, not even a message. Each now retries once, then shows the placeholder. The lightbox had no swipe, no prev/next and no arrow keys, so browsing 300 photos meant closing and reopening the modal for every one — while FEATURES.md and USER_JOURNEYS both claimed swipe shipped. It now has chevrons (44px, German aria-labels, hidden at the ends), arrow keys, and horizontal swipe, with focus handed to the surviving control so a disappearing chevron can't drop focus to `<body>`. Comment deletion was a ~14px `✕` four pixels from the text that deleted permanently on one tap, while deleting a POST two components away goes through a ConfirmSheet; it now matches. `feed-filter.ts` and its test are deleted — with the server filtering, they were dead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 18:36:05 +02:00
Fabian Hamm (Privat)	43d37269b6	deploy: pull prebuilt images instead of building on the event server ... The production compose still carried `build:` keys and no `image:` keys, so a `git clone` onto the CX22 followed by `docker compose up -d` would have started a fat-LTO release build of 427 crates on a 2-vCPU/4 GB box — the outcome the whole build-on-the-Mac decision exists to avoid, reached silently because `pull` skips a service it is told to build rather than failing. Both services now pull `registry.mc02.dev/eventsnap/*:${EVENTSNAP_VERSION}` with the `:?` form, so a missing tag fails the command instead of resolving to an empty one. `docker-compose.build.yml` restores the `build:` keys for the workstation that produces the images, from the same context paths. Also here: - `DOMAIN` gets the same `:?` guard. Blank did not fail — it produced `https://` for the frontend's ORIGIN and collapsed the Caddyfile's site block into a malformed global block, so the stack came up with no TLS and no site. - `stop_grace_period: 20s` on the app. Docker's default stop timeout is 10s, exactly the app's own drain budget, so a redeploy could SIGKILL the process at the moment it was finishing — truncating the in-flight upload the graceful shutdown protects. - `COMMENTS_ENABLED` is pinned "false" alongside MEDIA_PATH. It is a product decision for this event, and `.env.example` ships the generic `true`; pinning it means an operator who copies the example and edits only the secrets cannot ship comments on. - The frontend runtime stage now copies the lockfile and uses `npm ci`. Without it the three `^`-ranged deps re-resolved at build time, so an image rebuilt days later could differ from the one that was tested. Image also drops 120 MB -> 65 MB. - `docker-compose.dev.yml` told the operator that production had the same `$`-eating bug and to escape the hash as `$$` in `.env`. That is wrong and it breaks a working deployment: Compose uses single-quoted env_file values literally, and doubling produces a 74-character string `looks_bcrypt` rejects. Verified with `printenv`. The runbook's rollback pointed at `v0.12.0`, which has 6 migrations against HEAD's 22 and was never built or pushed — running the emergency card's rollback line would have crash-looped the app with `VersionMissing` during the event. §9 now has you tag one build twice so the rollback target is bit-identical, and says plainly what that can and cannot fix. Every `$DOMAIN` command gained the `set -a; . ./.env` it needs, the down-migration psql commands are wrapped in `sh -c` so the container expands the credentials rather than sending `-U ""`, and the advice to lower `max_video_size_mb` is withdrawn: the client guard it was premised on does exist, but is pinned to a compile-time constant, so lowering the DB value only moves failures later. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 18:34:07 +02:00
MechaCat02	f275de5c8f	perf(feed): stop every feed page from aggregating the whole event ... v_feed computed like_count/comment_count with LEFT JOINs and a GROUP BY. Postgres CAN push `event_id = $1` and the keyset predicate through the view — verified with EXPLAIN, it uses idx_upload_event_created_id — but it CANNOT push ORDER BY ... LIMIT across a GroupAggregate. So every request aggregated every upload in the event, times its likes and comments, and only then sorted and took 21 rows. Cost grew with the event, not with the page. Measured on a throwaway database seeded to a real reception (1000 uploads, 100 guests, 27k likes, 10k comments), same query, same data: before GroupAggregate (actual rows=1001) -> Sort -> Limit 449 ms after Index Scan (actual rows=21) -> Limit -> SubPlans 0.58 ms migration 022 replaces the joins with correlated scalar subqueries, which puts the counts ABOVE the Limit so they run 21 times instead of 1001. Exactly equivalent, not merely close: "like" is keyed (upload_id, user_id) so COUNT(DISTINCT user_id) == count(*), comment.id is the PK so COUNT(DISTINCT c.id) == count(*), and the GROUP BY was on u.id so it was already one row per upload. Column names, order and types are unchanged, so no Rust changes. No new index needed — idx_like_upload and idx_comment_upload already match the subqueries. Note the existing load harness cannot see any of this: e2e/loadtest/driver.mjs creates no likes and no comments, so the expensive path had never been exercised. The amplifier, feed/+page.svelte: every open feed subscribed to `upload-processed` and refetched page 1 — the most expensive page — so ~100 open feeds each fired one per completed upload. Now gated on whether this client actually shows the card that changed, and the debounce is jittered, because a fixed delay just moves a simultaneous herd 800 ms later. Nothing is lost by skipping: a client without the card also missed its `new-upload`, and the reconnect `feed-delta` already schedules a refresh. Load shedding, because the above reduces the risk rather than removing it: db.rs set no acquire_timeout, so sqlx's 30 s default applied — longer than the frontend's own 20 s fetch timeout, meaning the browser gave up while the server kept holding the slot and the work was done for nobody. Now 5 s, and PoolTimedOut maps to 503 + Retry-After instead of a generic 500. That mattered because the upload queue classifies 5xx as transient and retries: a 500 sent the retries straight back into the saturated pool with nothing to pace them. PoolClosed stays Internal — it only occurs during shutdown, where a 503 would invite a retry against a server that is going away. The Retry-After extraction in into_response matches on variants, so unlike message() a missing arm is not a compile error — it would silently drop the header. Pinned by a test covering both retry-carrying variants. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 23:01:42 +02:00
MechaCat02	3f0f9c098b	fix(upload-queue): rehydrate the persisted queue app-wide, not only on /upload ... loadQueue() had exactly one call site in the entire frontend: the /upload route's onMount. So after a reload, an iOS tab discard or a PWA relaunch, staged photos sat in IndexedDB while the badge read 0 and nothing sent them — unless the guest happened to navigate back to /upload, which they have no reason to do, having already been shown a success. The photo never leaves the phone and the guest is never told. The root cause was narrower than "loadQueue isn't called enough". requeueRetriable() read IndexedDB but only .map()'d over whatever the in-memory store already held, so it could reset statuses and never ADD an entry — and processQueue reads only that store. That is why the `online` listener and the SSE resume hooks, which both call it, could not recover a cold start either. It now REBUILDS the store from IndexedDB, which makes all three resume paths work. Rebuilding needs one guard: entryToQueueItem downgrades `uploading` to `pending` with progress 0, and this runs on every `online` event and every SSE reconnect, so a blind rebuild would visibly reset the progress bar of a request still on the wire. In-flight items are carried over by id. Hydration is module-level, SSR-guarded and idempotent, re-armed via onSetAuth/onClearAuth because login is a client-side goto() — no module re-import, no onMount re-run — so a hydration that no-oped for lack of a token gets a second chance. Module level rather than a layout onMount because +layout.svelte already imports this module on every entry point, it matches the file's own bindOnline()/bindSse() pattern, and a store owning its own persistence keeps the layout free of a concern it cannot test. auth.ts does not import this module, so no cycle. The burst-queue e2e test no longer navigates to /upload after its reload — it now asserts the resume happens wherever the reload lands, which is the actual regression guard. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 22:58:26 +02:00
MechaCat02	6fd75adb27	fix(ops): bound logs, drain ffmpeg's stderr, and stop three silent hangs ... Six independent operational defects, none of which needed a new feature to fix. Log rotation. Docker's json-file driver is unbounded by default, and those files land on the HOST filesystem — outside every deploy.resources.limits in the compose file, and on the same disk as postgres_data and media_data. A full disk stops Postgres writing WAL, which takes the event down. Capped at 10m x 3 per service. Log level. RUST_LOG was set in neither .env.example nor docker-compose.yml, so the code fallback WAS the production level — and it was `debug`, with tower_http=debug emitting a line per request and per response into that unrotated file. Now info, with tower_http=warn to state that those spans are diagnostics, not an access log. ffmpeg pipe deadlock. run_ffmpeg piped stdout and stderr and then called wait(), which drains neither. Once the ~64 KiB pipe buffer filled, ffmpeg blocked writing and wait() never returned — burning the full 120s timeout, twice per seek position, three times per compression attempt. And the timeout is an Err, so the end state was a soft-deleted upload: a guest's playable video destroyed by a poster-frame failure. Now stdout is null (nothing ever read it) and stderr is drained by wait_with_output, whose tail is logged on a non-zero exit. Note wait_with_output consumes the child, so the old kill-on-timeout is gone; kill_on_drop(true) already covers it. Readiness probe. /health never touched the pool, so the disk-full endgame above stayed green all the way down. Adds /health/ready (SELECT 1 under 2s) as a SECOND route — the compose healthcheck deliberately keeps pointing at /health, because caddy gates its startup on it and a DB-dependent probe would turn a Postgres blip into the reverse proxy refusing to start. api.ts request timeout. The abort timer was cleared in a finally around fetch(), which resolves on the response HEAD — leaving res.text() uncovered and no longer abortable. An upstream that sends headers then stalls the body hung the call forever. The timer now lives until the body is read, including the 204 path (which otherwise leaked a live 20s timer per no-content request). Upload XHR watchdog. The XHR had no timeout while processQueue held the isProcessing latch across it; on a half-open socket neither error nor abort ever fires, so the latch pinned and the queue wedged. Bounds SILENCE rather than total duration — a 500 MB video over a venue uplink legitimately runs 30+ minutes while making steady progress. Rejects as NetworkError, which is already the retryable branch, so a stalled upload now recovers like any network blip. IndexedDB failures. addToQueue called getDb() unguarded and handleSubmit had no catch, so a private-mode refusal or a QuotaExceededError on a large blob left a permanent "Wird hochgeladen…" spinner, no toast, and — for an in-app camera capture — the only copy of the photo gone. Now reported as 'failed', which keeps the staged files on screen and stays on the page. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 22:25:23 +02:00
fabi	5f702f2b40	fix(audit-5): export disk preflight, media reclaim, low-disk warning, restore docs ... Fifth round, all storage. The keepsake could not fit on the documented hardware and failed halfway through a multi-GB write, leaving the deliverable stuck; the quota had stopped bounding the disk; and the backup had no restore procedure. Squashed from 6 commits, original messages preserved below. ──────── fix(export): refuse an export that cannot fit, and stop peaking at two generations Nothing in export.rs ever asked whether the keepsake would fit. Both archives write their media `Compression::Stored`, so each is essentially a byte-for-byte second copy of the originals -- Gallery.zip always, and Memories.zip for every video and every image at or under 5 MB. On the documented CX33 (80 GB, all three volumes on one filesystem) the upload quota's fixed point leaves ~40 GB free, and a release spawns BOTH halves concurrently against it. The failure is not "the export failed", it is "the deliverable is stuck": 1. ENOSPC lands partway through a multi-GB write. 2. The epoch has already moved, so the job row is `failed` at the CURRENT generation and readiness (epoch = event.export_epoch AND status = 'done') is false -- GET /export/zip 404s. 3. The last good archive sits on disk, unreferenced and unreachable. 4. POST /host/export/rebuild, the only escape, re-arms the same doomed write. Three changes. Reclaim before building. `prune_stale_export_files` ran only after the new archive was written, renamed and finalised. That reads as durability but buys nothing: the moment `invalidate_and_arm` bumps the epoch the old archive is ALREADY unreachable, so keeping it reserves gigabytes for a download nobody can perform -- and for a takedown it is content someone explicitly asked to have removed. Peak usage is now one generation. Narrower than the post-finalize prune on purpose: final archives only, never a `.tmp` or a `viewer_tmp_` dir, since a superseded worker can still be streaming into those and at build START is far more likely to be alive. Preflight the space. SUM(original_size_bytes) over exactly `query_uploads`' visibility filter, +10% for ZIP overhead, multiplied by the number of armed jobs -- without that multiplier each of the two concurrent halves independently sees "it fits" and together they don't. Runs AFTER claim_job, not before as reported: bailing before the claim leaves the row `pending` with no worker and no error, the spinner-forever state `mark_failed`'s status guard exists to prevent. Fails open when the mount can't be read, exactly as the upload quota does. Show the host the reason. /export/status returned {status, progress_pct} and nothing else, so the host dashboard could only render "fehlgeschlagen" next to the retry button. The message was written to the row and surfaced solely in the ADMIN job list -- a different screen, possibly a different person. It now travels with the status, and only on a failure, so a message left on a since-succeeded row can't appear beside a green "ist bereit". Tests: 10 unit (the u128 clamp caught a real bug in the first draft -- saturating_mul then /100 turns an overflow into a number ~100x too small, the one direction that authorises the write being guarded against; the carried-forward archive must survive its own older epoch in the filename), 4 DB-backed (the estimate is asserted against the row set the archive actually contains, not against a restatement of the WHERE clause, so the two queries cannot drift), 3 e2e over the four-hop plumbing. ──────── fix(maintenance): reclaim the media of deliberately deleted uploads The quota stopped bounding the disk. `soft_delete_in_event` stamps `deleted_at` and refunds `total_upload_bytes`, but nothing ever removed the bytes, and the hourly sweep reached only `compression_status = 'failed'`. Upload 500 MB, delete, quota back to zero, upload another 500 MB. Not an attack -- a guest curating their camera roll, which is what people do. The host then sees guests hitting "Du hast dein Upload-Limit erreicht" while the admin widget shows a disk full of files no upload row points at, and the quota message is actively misleading because the space really is gone, just not to anyone the accounting can name. Two retention windows, because the two deletes mean different things. A compression failure keeps its 14 days: the guest didn't ask for it and may not be able to retake the photo. A deliberate removal gets 24 hours -- 14 days outlives the whole event, so a deliberate delete would never reclaim anything while it mattered, and a day still covers a mis-tap. Wider than reported: ALL FOUR paths are reclaimed, not just the original. Preview, display and thumbnail are each a separate file, none counted in `original_size_bytes`, and nothing ever removed them either. That was invisible while the sweep only saw failed compressions (which produce no derivatives) and becomes three leaked files per upload the moment it reaches a successful one. A row is re-selected until every path is cleared, and the columns are cleared only once every file for that upload is gone -- clearing after a partial success would strand the survivors in exactly the unowned state this drains. `backfill_stale_derivatives` selects on `display_path IS NULL AND preview_path IS NOT NULL`, which is close enough to the post-sweep state to be worth pinning: it is guarded on `deleted_at IS NULL`, so it cannot re-decode an original that is no longer on disk. Covered. Residual, deliberately: within the 24h window the bytes are still spent and still unaccounted, so delete-and-re-upload through an eight-hour event can outrun the sweep. Bounding that means holding the quota until the file is reclaimed rather than refunding at `deleted_at`. The low-disk warning is the net under it. Tests: 6 DB-backed, replacing 3. The one asserting an owner-deleted upload IS reclaimed is the exact inverse of what this file used to assert. ──────── feat(host): warn about low disk before it becomes unrecoverable Storage visibility existed in exactly one place: a passive Speicherauslastung widget on the ADMIN dashboard. A host who isn't the admin had no view of it, and nothing warned anyone. README carried "Low-disk alert (< 10 GB free)" under Planned since v1. Two things make this a safety net rather than a nice-to-have. postgres_data, media_data and exports_data are all Docker named volumes on ONE filesystem, so running out doesn't degrade a subsystem -- Postgres stops being able to write and the whole event goes down. And the keepsake needs room for two gallery-sized archives, which the export preflight can only ever refuse AFTER the release, when the event is over and every remedy is harder. So the threshold is not a fixed number alone. It fires on the 10 GB floor the README always named, OR on "you could not build the keepsake right now" -- the trigger a host can still act on, computed with the same arithmetic the preflight uses. Unknown free space is NOT low: it fails open like the upload quota and the preflight do, because a banner that cries wolf on an unreadable mount is a banner nobody reads. Carried on GET /host/event, which the dashboard already fetches on load and on every reload -- no new endpoint, no new poll. Rendered above everything else including the PIN-reset queue, and it names the consequence (the event, not just the download) rather than only the number. Also fixes the host page's formatBytes, which topped out at MB: 30 GB free would have rendered as "30720.0 MB", and a guest with 2 GB of uploads was already being shown that way in the user list. Tests: 5 unit on the threshold (including that plenty of free space is still low when the keepsake wouldn't fit -- the case a fixed threshold misses entirely), 3 e2e. The e2e drives it through `original_size_bytes` rather than a genuinely full disk: the estimate is pure SQL over that column, so overstating one row moves the accounting without touching a byte on disk. ──────── docs: add a restore procedure, fix the backup cadence, and correct quota_tolerance Four things, all found by the same question: what does an operator standing at the venue actually need? A RESTORE PROCEDURE. There was none anywhere, and a backup you have never restored isn't a backup. Two hazards worth writing down: media must be extracted preserving ownership (the app runs as uid 100 / gid 101, and a root-owned restore makes every upload fail with EACCES surfacing as a generic 500), and the app must be STOPPED first, because migrations run on boot and a live pool will fight the restore. Both the backup and the restore commands were run against the real stack before being written down, which caught two that would have failed: - The plain `pg_dump` did not restore: `psql` aborted on `ERROR: schema "_sqlx_test" already exists`. pg_dump emits no DROPs without --clean --if-exists, so the documented dump could only ever be restored into an empty database. Fixed at the source (the dump is now self-cleaning) and verified end to end: 16 tables back, exit 0. - `--same-owner` does not exist in BusyBox tar, which is what `alpine` ships, so the extract aborted before unpacking anything. `--numeric-owner` plus the explicit chown, verified to land 100:101. BACKUP CADENCE. "Weekly offsite" is the wrong shape when every irreplaceable byte is created in one eight-hour window and nobody can retake a wedding. The backup that matters runs that night, and again after the release so the keepsake is captured. Also: take the DB dump and the media tarball back to back, or you get rows pointing at files the dump doesn't know about. quota_tolerance WAS DOCUMENTED AS SOMETHING IT ISN'T. .env.example called it "fraction of disk that triggers the low-storage warning". It is the multiplier in `floor(free_disk * tolerance / active_uploaders)` -- so an operator who wants "warn me later" and sets 0.95 is actually authorising guests to fill 95% of the disk, moving the fixed point from 43% to ~49% and eating the export headroom. The admin UI labelled it "Toleranz (0-1)" with no explanation at all, which invites exactly that reading; it is now "Speicher-Anteil für Gäste" with the formula in the hint. Wrong docs on a tuning knob are worse than no docs. SIZING. New section with the arithmetic: three volumes on one filesystem, the quota fixed point at tolerance/(1+tolerance), and the fact the 80 GB baseline does not cover the keepsake -- both archives are built concurrently and each is roughly a second copy of every original. Provision ~3x expected media, or give exports its own volume. Also ticks the low-disk alert off the roadmap, since it now exists. ──────── chore: raise the db memory limit and rate-limit social writes Two smaller operational items. POSTGRES 512M -> 1G. DATABASE_MAX_CONNECTIONS is 30 for a ~100-guest event (feed polling + SSE + uploads at once), and 30 backends plus Postgres 16's default shared_buffers leaves very little headroom at 512M. An OOM here doesn't degrade one feature -- every request path touches the database, so it takes the event down. Memory is the cheaper knob than shrinking the pool back and reintroducing the queueing it was raised to fix. .env.example now names the pairing explicitly, the way it already does for COMPRESSION_WORKER_CONCURRENCY. SOCIAL WRITES WERE UNTHROTTLED. toggle_like, add_comment and delete_comment were the only mutating endpoints in the app with no limit at all -- upload, join, recover, export and admin login all carry one. Asymmetric coverage rather than a deliberate decision. Low severity, and honestly so: a like fans an SSE broadcast to every client, but the export regeneration a comment deletion triggers is contained (REGEN_DEBOUNCE 20s, workers born with their epoch, superseded ones inert). So the ceiling is 120/min -- far above anything a real guest produces. This bounds a script, not an enthusiastic double-tapper. ONE bucket across all three actions: separate buckets would let a caller triple the aggregate write rate by alternating between them. Keyed per USER, matching the feed and upload limits -- at a venue every guest is behind one NAT, and an IP key is what made the /join and /feed limits turn guests away in the first place. Migration 020 seeds both keys, and both are wired into the admin allowlist, the config UI and the e2e reseed -- the step two earlier per-area toggles missed, which left switches that existed in code and could never be flipped. Tests: 4 e2e, including that the shared bucket really is shared (the part most likely to be lost in a refactor) and that one guest hitting the ceiling doesn't block another behind the same IP. ──────── fix(e2e): stop the video poster assertion racing the ffmpeg thumbnail Pre-existing, and it fired for real during the full-suite run on a cold stack. The lightbox binds `poster={upload.thumbnail_url ?? undefined}`, so the attribute is absent until compression produces the thumbnail. This test asserted on it immediately after seeding, never waiting for the worker -- unlike the Range test further down the same file, which does poll. Against a warm stack the worker usually wins; against a freshly rebuilt one (`stack:down -v`, cold ffmpeg) it doesn't. That is the worst possible time for a false failure: the first run after a rebuild is exactly when you are trying to establish whether a change broke something. Poll for `compression_status = 'done'` before the poster assertion. The `src` assertion needs no wait and keeps none. Verified with --repeat-each=3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 20:10:54 +02:00
fabi	b601c062bd	fix(audit-2): video playback, role identity, keepsake EXIF, recover ceiling, WebKit CI ... Second round: the two regressions the first round introduced, the remaining gaps it left, and the CI change that makes the iOS guarantees actually gate a change rather than being asserted. Squashed from 9 commits, original messages preserved below. ──────── docs(deploy): document the update path — `up -d` alone ships nothing The README only ever described a fresh install. There was no update section anywhere, and `--build` appeared nowhere in the docs. That matters because `app` and `frontend` are `build:` services with no published image tag, and Compose has no source-change detection: if an image by that name exists it is reused. So the natural `git pull && docker compose up -d` reports "Container app-1 Running", rebuilds nothing, and exits 0. A deploy that shipped none of the new code is indistinguishable from a successful one — which is how eleven merged fixes can sit in the repo and never reach the box. Verified both halves against a real stack rather than asserting them: with a source change staged, `up -d` left the image ID untouched; `up -d --build` produced a new image ID and a healthy /health. Adds an "Updating an existing deployment" section covering backup-before-migrate, pull, rebuild, health check, and an image-ID comparison to prove a build actually happened. Also spells out the rollback trap: migrations run on boot and are not undone by checking out an older commit, so rolling back code without restoring the snapshot leaves the schema ahead of the binary and the app refusing to start. ──────── fix(video): play the actual video, and answer Range requests Every video in the app was unplayable. Two independent defects, either one sufficient on its own, and nothing in the suite covered either — no test anywhere played media or asserted a `<video>` src. 1. The lightbox handed `<video>` a JPEG. `pickMediaUrl` is mime-agnostic, and compression only ever produces a THUMBNAIL for a video (one `ffmpeg -vframes 1` frame) — no preview, no display. So in the DEFAULT saver mode the element's src resolved to `/api/v1/upload/{id}/thumbnail`, served as `image/jpeg` with `nosniff` so the browser can't even sniff its way out. Chromium reports DEMUXER_ERROR_COULD_NOT_OPEN. Fixed in the lightbox rather than in `pickMediaUrl`: FeedListCard shares that helper and legitimately wants the thumbnail for its `<img>` poster, so a central mime branch would break the feed. This mirrors the rule the diashow already applies ("videos play the original file directly"). Added `preload="none"` so saver-mode guests on cellular still fetch nothing until they press play — there is no smaller video derivative to offer them — plus `playsinline`, without which iOS hijacks playback into fullscreen. 2. `stream_media_file` ignored Range entirely. It took no request headers, so it could not see `Range`; it always returned 200 with the whole body and never sent Accept-Ranges or Content-Range. iOS Safari opens every `<video>` with a `Range: bytes=0-1` probe and abandons the load without a 206 — so video failed on the app's primary platform even in `original` mode, where the src was already correct. Adds single-range support (`bytes=N-`, `bytes=N-M`, `bytes=-S`) with 206 + Content-Range, 416 + `bytes */len` past EOF, and Accept-Ranges advertised on every response. Anything it won't handle — multi-range, non-bytes units, garbage — falls back to a full 200, which RFC 9110 explicitly permits and which is safer than guessing. All four media routes share the helper, so seeking works uniformly. `get_original` now serves `inline` instead of `attachment`. An attachment disposition is hostile to a `<video>` element, and this route is the only source of playable video bytes; it also matches what the UI promises, since the action is labelled "Original anzeigen" — view, not download. `no-store` is deliberately kept so a takedown still revokes access promptly; ranges work fine under it, the client just re-fetches. Tests: 11 unit tests pin the parser (the iOS `bytes=0-1` probe, inclusive ends, suffix ranges, clamping past EOF, 416 vs 200, malformed fallbacks). A new 03-feed/video-playback spec asserts the src is the original and not the thumbnail, that the browser accepts the bytes as media (readyState > 0, no MediaError), that no video bytes are delivered before play, and that Range returns the correct 206 slices and a 416 past EOF — verified on both Chromium and WebKit. The "not downloaded before play" test asserts no *delivered body* rather than no request: WebKit opens a connection for a preload="none" video and immediately aborts it (GET, no Range, status 0, nothing transferred) while Chromium issues nothing at all. The portable guarantee is that no response carrying bytes completes. ──────── fix(auth): bind the role store to the identity, not to the tab The role store I added in the moderation work is a module-level singleton seeded ONCE at import. `goto()` is a client-side navigation, so leaving and re-joining in the same tab re-imports no module and re-runs no onMount — the previous user's role simply stayed resident. Nothing reset it: not join, recover, admin login, "Event verlassen", `clearAuth`, nor the api.ts 401 auto-clear. So a host who left, followed by a guest joining on the same phone, left that guest with `isStaff === true` and a "🚫 Beitrag entfernen" action on other people's photos. The backend 403s the delete, so this was a false affordance rather than a privilege escalation — but `/feed` never fetched `/me/context`, so unlike every other route it never self-corrected either. It survived until a hard reload. The mirror case was equally broken and easier to overlook: a guest who recovered into a host account got NO host affordances. `clearAuth` already had a hook registry for exactly this shape of problem, with a comment explaining it exists to avoid circular imports. Add the missing mirror, `onSetAuth`, fired by both `setAuth` and `setAdminAuth` after the new token is resident, and have the role store register on both sides: clear to null on logout, re-seed from the new token on login. That also gives `syncRoleFromToken` — dead code with zero callers since I introduced it — its intended purpose. Seeding from the claim fixes the reported bug, but the claim is frozen for the token's 30-day life, so a promotion or demotion still wouldn't reach the feed. `/feed` now calls the existing `refreshEventState()` on mount, which fetches `/me/context` and applies both the authoritative role and the lock/release state in one request. The feed is the one route gating a destructive action on the role, so it should not be the only route running on a stale claim. Tests: 04-host/role-identity-reset drives the real flows. The first asserts the host DOES see the action before asserting the newcomer does not — a negative assertion alone would pass against a build that shipped no moderation at all. The second covers the mirror, promoting a guest server-side while their resident token still claims `role: guest`, so a fix that only cleared the role would fail it. ──────── fix(compression): reclaim failed originals instead of leaking them Round 1 stopped the compression worker deleting an upload's original on failure — a transient ENOSPC or a codec panic must never destroy the only copy of a photo a guest cannot retake. But it left `Upload::soft_delete`'s quota refund in place, so the bytes stayed on disk while the uploader was charged nothing for them. That is worse than it first looks. The row is soft-deleted, so the file is invisible and unowned; a guest hitting a reproducible codec failure can accumulate orphans indefinitely at zero personal cost. And `active_uploaders` counts only users with non-deleted uploads, so dropping out of that count RAISES everyone's per-user ceiling — the leak loosens the very quota meant to contain it. Keep the refund: the uploader didn't cause the failure and shouldn't silently lose quota to it. Bound the leak instead, with an hourly sweep alongside the existing session cleanup in `spawn_periodic_tasks`, reclaiming failed originals older than 14 days — comfortably longer than any single event, so an operator investigating a failed upload still has the file. The selection predicate is the entire safety argument, so it is deliberately narrow: `compression_status = 'failed'` AND soft-deleted AND past the window AND `original_path <> ''`. That is exactly the state the give-up path leaves behind, and it cannot reach a live upload, an owner-deleted one, or a failure still inside its recovery window. `original_path` is cleared after a successful reclaim, which makes the sweep idempotent — otherwise a row whose file is already gone is re-selected on every tick forever. The row itself is kept as the audit trail. Tests reproduce the selection verbatim (same pattern as upload_concurrency) and assert it against five near-misses that must survive, both sides of the retention boundary, and the idempotence property. Also fixes two comments in export.rs still claiming "the compression worker hard-deletes an original when its transcode fails" — no longer true, and the defensive handling they justify is now justified by this sweep and by ordinary deletes instead. ──────── fix(export): apply EXIF orientation in the keepsake too Round 1 fixed EXIF orientation in the compression worker, which corrected the live app — feed preview and diashow display. The export worker was missed, and it does not reuse those derivatives: it re-decodes the originals itself with `image::open`, which ignores the orientation tag, then re-encodes to JPEG, which drops the tag — so the viewer has no way to recover it. The damage was oddly shaped, which is exactly why it reads as a viewer bug: Gallery.zip originals correct (byte-copied, EXIF intact) Memories viewer grid thumbnails SIDEWAYS (always) Memories viewer full image >5 MB SIDEWAYS (re-encoded at 2000px) Memories viewer full image ≤5 MB correct (streamed byte-for-byte) So in the keepsake people actually keep, every portrait photo in the grid was on its side, and clicking through silently "fixed" small photos but not large ones. Rather than paste the decoder dance a third time, extract `services::imaging:: decode_oriented` and route both workers through it, so there is exactly one way to turn a file on disk into a DynamicImage. It carries a second invariant that had also drifted: `image::open` applies NO decode limits, so the export path was decoding arbitrary user-supplied images unbounded — the decompression-bomb cap existed only in the compression worker. Both now come as a pair, which is the point of having one function. Not done: switching export to consume the existing `display` derivative. It would fix orientation and drop a redundant full-resolution decode per photo, but it would also replace the pristine ≤5 MB originals in the keepsake with 2048px re-encodes — a real quality regression in the one artefact people keep forever. Test uploads the round-1 fixture (40x20 landscape tagged Orientation=6), runs a real export, pulls the thumbnail out of Memories.zip and asserts it came back portrait — with a sanity check that the source really is stored landscape, so the test can't pass against a pipeline that does nothing. ──────── fix(recover): cap name cycling, and stop bcrypt blocking the runtime Round 1 gave /join a per-IP ceiling and left /recover with only its `recover:{ip}:{name}` bucket. That key is right for the job it was written for — stopping someone who knows a display name (they're listed on the feed) from burning the victim's 3-strike PIN counter and locking them out on repeat. But the name is ATTACKER-CHOSEN, so cycling names mints a fresh 5-attempt bucket every time and the per-IP cost is unbounded. What sits behind that limiter makes it worse than a normal flood: every call runs a cost-12 bcrypt verify, including an UNCONDITIONAL throwaway verify for names that don't exist — added deliberately to close a timing oracle. So an unknown name is the single cheapest way to make the server do ~200ms of hashing. Adds `recover_ip_rate_per_min` (default 30, migration 019), checked BEFORE the per-name bucket so a name generator can't walk past it. 30/min is far above any real recovery attempt while capping a flood. The per-name bucket is untouched and remains the anti-guessing control. The second half matters as much as the first: bcrypt was running inline on the async runtime everywhere. At cost 12 that pins a tokio worker thread for ~200ms, and there is only one per core — so a login flood stalled every other request on the box, including the feed. There was no spawn_blocking anywhere in the auth module, despite SECURITY-BACKLOG claiming bcrypt had been offloaded. Route all of it through `verify_password` / `hash_password` on the blocking pool. That covers /recover, /admin/login, the host PIN reset, and — the one most likely to bite at a real event — the PIN hash minted on every single /join. Saturating the blocking pool degrades logins; saturating the worker threads degrades everything. Tests: cycling distinct names from one IP now hits the ceiling with a Retry-After, and — the assertion that keeps the fix honest — repeated wrong PINs against ONE name are still throttled with the ceiling set generously high, so the ceiling added protection rather than replacing it. ──────── ci(e2e): run WebKit, so the iOS guarantees actually gate a PR The workflow installed only Chromium and ran chromium-desktop + chromium-mobile. iOS Safari is the app's stated primary user — a wedding guest opening a QR link — and WebKit is the only engine in the matrix that reproduces two of its behaviours: - it enforces X-Frame-Options on the hidden download iframe, so a site-wide DENY makes the keepsake download silently do nothing. Blink hands attachments to the download manager before the frame check and never notices. - it abandons a <video> load unless its Range probe gets a 206. Both of those shipped. Adding 06-export to the webkit project in the round-1 fix bought nothing on a PR, because CI never ran that project at all — the regression test written specifically to catch the blocker only ever executed locally. Runs 71 tests (67 pass, 4 skip on the documented IndexedDB-blob harness limitation) in ~1.5 minutes locally, using the exact command added here. ──────── chore(backend): satisfy cargo fmt `checks.yml` runs `cargo fmt --check`, and it has been failing since the round-1 audit fixes: I gated those on `cargo build` and `cargo clippy` but never ran fmt, so three files drifted then and eight more this round. Pure formatting — no behaviour change; clippy stays at zero and all 70 backend tests still pass. Worth noting for next time: clippy passing is not evidence fmt does. ──────── chore: satisfy prettier in frontend and e2e `checks.yml` runs `npm run format:check` for both projects and both were failing. - frontend/src/lib/ui-store.ts is mine, unformatted since the round-1 upload-queue badge fix — the same miss as the rustfmt one: I gated on svelte-check and eslint but never on format:check. - e2e/loadtest/* and e2e/shots.mjs have been unformatted since 7758270 and are unrelated to the audit work. Fixed here because they block the same gate and the fix is mechanical; no behaviour change in either project. Still red and deliberately NOT fixed here: `npm run lint` in the frontend reports `svelte/prefer-svelte-reactivity` on routes/diashow/+page.svelte:208 (a mutable `Set` where the rule wants `SvelteSet`), pre-existing since 5009590. That one is a real reactivity change in code I have no test coverage for, so it belongs in its own change rather than smuggled into a formatting commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 21:28:11 +02:00
fabi	0c0eed885a	fix(audit-1): media gating, per-user limits, moderation UI, upload integrity ... First audit round: a blocker and eight high-severity findings across the media access gate, the guest-facing rate limiters, host moderation, and the upload pipeline — plus the backup commands and the e2e/production divergences that hid several of them. Squashed from 7 commits, original messages preserved below. ──────── fix(export): let the keepsake download through X-Frame-Options on iOS The keepsake download navigates a hidden, same-origin iframe (deliberately: a top-level navigation to a 404/429 would unload the PWA). Caddy stamped a site-wide `X-Frame-Options: DENY` that also covered the proxied `/api/*`. Blink hands a `Content-Disposition: attachment` response to the download manager at the network layer, so Chromium never noticed. WebKit enforces XFO on the frame navigation first and aborts the load — so on iOS Safari, the app's primary platform, tapping Download did nothing at all, silently. Carve the two export endpoints out to SAMEORIGIN, which still blocks cross-origin framing. Implemented as two disjoint matchers rather than an override: Caddy applies the FIRST `header` directive outermost, so it wins on write and a later, more specific `header` is silently ignored (verified against the running test stack). Also close the test gap that let this ship: - `06-export` ran on chromium-desktop only; add it to `webkit-iphone`, the only engine that enforces XFO on the download frame. - No test in the suite ever clicked a download button — every archive assertion used Node `fetch`, which has no frame and no XFO enforcement. Add a spec that clicks it and awaits a real `download` event. Verified falsifiable: with the blanket DENY reinstated it fails and reports the WebKit refusal as the cause. - Fix `ExportPage`'s card-scoped locators, which matched nothing: the cards carry `class="card p-5"` (a Tailwind `@apply` component class), never the `rounded-xl` the page object looked for. This had left the "shows enabled download buttons" test red on main. ──────── fix(media): close the percent-escape bypass of the media gate `/media/%70reviews/{id}.jpg` served a taken-down photo to anyone, unauthenticated. Verified against the running stack: the literal path 404s, the escaped one returned 200 with the full image. Same for displays, thumbnails and originals, and any escaped byte in any position works. Cause: the block was four `nest_service("/media/previews", 404)` route matches sitting above a `ServeDir` on `/media`. axum matches on the RAW path (matchit does no percent-decoding), while `ServeDir` percent-decodes when it resolves the file. So `%70reviews` missed every blocker, fell through to the ServeDir, and was decoded back to `previews/` on disk — reaching the bytes with no soft-delete and no ban-hide check. That defeats a host takedown, which is the entire point of the gate. Remove the `/media` route tree outright instead of racing the decoder. Nothing needs it: every media URL the backend emits is already a gated `/api/v1/upload/{id}/{original,preview,display,thumbnail}` alias (handlers::feed), the frontend contains zero `/media/` references, and the `/media` in config.rs/disk.rs is the filesystem path while `media/` in export.rs is a path inside the zip. `/media/**` now 404s regardless of encoding. The route's own comment already said it "serves nothing" — it wasn't a backstop, it was the vector. Caddy keeps proxying /media/* deliberately: the app 404s it, and forwarding means the e2e gating specs exercise the app's refusal exactly as production would rather than being masked by the SvelteKit 404 page. Extend the gating spec with the encoded variants — asserting only the literal spelling is what let this sit undetected. ──────── fix(rate-limit): key the guest-facing limiters per user, not per IP At a venue every guest is behind one NAT, so an IP-keyed limiter hands the whole party a single bucket. On a fresh deploy 12 guests arriving together meant 5 joined and 7 were turned away, with no Retry-After telling them when to retry. `/feed` (60/min) and `/export` (3 per DAY — the fourth guest to fetch their keepsake locked out until tomorrow) had the same defect. `feed_delta` was already keyed per-user and its comment states the exact rationale ("so one client can't starve others behind a shared NAT"); this makes its siblings match. - feed:{ip} -> feed:{user_id} (auth was already in scope) - export:{ip} -> export:{user_id} (resolved from the download ticket's session, which was previously looked up and discarded) - join:{ip}: pre-auth, so there is no user to key on. Split in two — a loose per-IP ceiling that only bounds raw volume (new `join_ip_rate_per_min`, default 60, migration 017), plus the real 5/60s anti-spam bucket keyed per (ip, name), mirroring the existing `recover:{ip}:{name}`. admin_login / recover / pin_reset_req stay IP-keyed on purpose and are now commented as such: they guard credential guessing, where a per-user or per-name key would just hand an attacker a fresh bucket per guess. Retry-After: the machinery existed but 7 of 8 sites called `check()` and hard-coded `None`, so a throttled client was told to back off but never for how long. Delete the bool `check()` wrapper entirely so `check_with_retry` is the only entry point and the delay cannot be discarded by accident. Also surface it for the PIN lockout, where the deadline was already known. Fix the "unknown" fallback while here: every client_ip() caller passed that literal, so any request without X-Forwarded-For — anything reaching the app directly rather than through Caddy — shared ONE global bucket. Serve with connect-info and use the peer address. Tests: the reseed forces every limiter toggle off before each test, which is why this whole class was invisible. Add 01-auth/rate-limit-shared-nat, which enables them and asserts 12 guests share an IP without collision, that one guest hammering their own name IS still throttled (so the fix re-keys rather than removes the limit), and that feed/export buckets are per-user. Retarget the ddos join test at the new per-IP ceiling — it asserted the defect. Also seed `admin_login_rate_enabled` (read by the handler, seeded by no migration and no reseed) and register `join_ip_rate_per_min` in the admin config allowlist. Unrelated pre-existing red test fixed: 01-auth/join asserted a "Willkommen!" heading the wedding redesign removed. ──────── feat(moderation): let a host remove a guest's photo or comment from the UI `DELETE /host/upload/{id}` and `DELETE /host/comment/{id}` were complete on the backend — transactional, SSE-broadcasting, audit-logged — and had zero frontend callers. The feed context sheet offered "Löschen" only when `target.user_id === myUserId`, so the only lever a host actually had against an unwanted photo was banning the uploader. That is both disproportionate and ineffective. A ban doesn't retract what was already posted, and it makes things strictly worse for comments: the ban check runs BEFORE the ownership check on the guest delete route, so banning an abusive author leaves their comment on screen and permanently undeletable by them. With no host affordance, nobody could remove it at all. - feed: hosts/admins get "Beitrag entfernen" on other people's posts, routed to the host endpoint (the guest route 403s anything the caller doesn't own) with moderation-specific confirm copy. Own-post "Löschen" is unchanged. - lightbox: same for comments, via /host/comment/{id}. - Ban semantics are deliberately untouched (USER_JOURNEYS §10 — banned users keep read access and cannot write). The deadlock is broken by giving the host a way in, not by loosening the ban. Live role (this had to come first). `getRole()` decodes the JWT claim, but the token is never reissued — the backend slides the session row forward and treats the DB row as authoritative. The claim is therefore frozen for the token's lifetime: up to 30 days. A guest promoted at the party saw no Host-Dashboard and no moderation actions until they signed out and back in, even though `/me/context` had been returning their real role on every page load and 4 of its 6 call sites dropped the field on the floor. Add `role-store.ts`: seeded from the claim so there's no flash of the wrong nav, then corrected by every `/me/context` response. Point the ad-hoc `getRole()` callers at it (account, upload, host, admin, and the new feed gate). The host and admin dashboards now derive `myRole` reactively, so a demotion disables their controls immediately instead of at next login. Tests: 04-host/moderation-ui drives the real UI — host removes a guest photo and it's gone from /feed server-side; a plain guest is offered nothing on someone else's post (the mirror that keeps the first test honest); a promoted guest gains the dashboard on reload while their token still carries `role: guest`; and a host removes the comment of an already-banned guest, asserting first that the author's own delete 403s so the deadlock is real. ──────── fix(upload): stop destroying originals, apply EXIF orientation, surface rejections Three defects in the same pipeline, each of which loses a photo or misrepresents one. 1. A transient error destroyed the guest's only copy. `process`'s error arm unconditionally `remove_file`d the original. Every failure routed there: `create_dir_all`, both derivative `save_with_format` calls (disk full is the canonical case, and it arrives exactly when many guests upload at once), a panic inside the image codec, or a momentary DB-pool exhaustion. The row is only SOFT-deleted, so the bytes were the sole unrecoverable part — and they were the part we deleted. The author already knew this was wrong next door: `backfill_missing_display` says it "must NEVER soft-delete an upload that already has a working preview". Retry up to 3 times with backoff (re-checking the e2e generation guard after each sleep), and on final failure keep the refund + soft-delete but leave the original on disk, logging its path. A failed upload is now recoverable instead of gone. 2. Every portrait photo was stored sideways. Phones don't rotate sensor data — they record the camera orientation in EXIF and store the pixels as shot. `decode()` returns those raw pixels and the JPEG re-encode writes no EXIF, so the 800px preview, the 2048px diashow display and the keepsake were all rotated 90°, while "Original anzeigen" rendered upright because the original keeps its tag. That asymmetry is why it reads as a viewer bug. There was no EXIF handling anywhere in the repo and no exif crate. Read the tag via `into_decoder()` (which carries the decode Limits through, so the decompression-bomb cap is untouched) and apply it. Missing/malformed tags fall back to NoTransforms — most images have none. Existing derivatives are already baked wrong, so migration 018 adds `derivatives_rev` and `backfill_missing_display` becomes `backfill_stale_derivatives`: it now also picks up anything below the current rev and regenerates it once from the original, which still carries its EXIF. Videos are marked current in the migration — ffmpeg already honours the rotation matrix. Bump DERIVATIVES_REV for any future change that invalidates derivatives. 3. A rejected upload vanished without a word. `UploadQueue.svelte` — 162 lines holding the ONLY renderer of an item's error text, the only "Erneut" retry button and the only rate-limit countdown — was never imported anywhere, so `retryItem`, `removeItem` and `clearCompleted` were unreachable at runtime. On a terminal rejection the store purged the blob and wrote a clear German reason into `entry.error` "so the UI shows a clear reason". There was no such UI. And `uploadBadgeCount` counted only pending/uploading, so the badge decremented exactly as if the upload had succeeded. Mount the queue on /upload, toast the reason immediately (the flow sends the user to /feed straight after staging, so the list alone would still miss them), and count blocked/error in the badge so a failure can't read as success. Tests: 02-upload/exif-orientation uploads a 40x20 fixture tagged Orientation=6 and asserts both derivatives come back PORTRAIT, with a sanity check that the source really is stored landscape. 02-upload/rejection-visible bans the uploader between staging and sending, then asserts the toast, the queue row with the server's reason, and that the item is still counted. Note: 02-upload/quota's 4 failures are pre-existing and unrelated — see the next commit. ──────── docs(backup): make the backup commands work; fix the e2e/prod divergences Backup. Both documented commands failed on the shipped stack, and the sentence explaining them was wrong too: - `pg_dump $DATABASE_URL` — `DATABASE_URL` is only ever in the compose environment, never an operator's shell, and it points at `db:5432`, which is compose-internal DNS. The app image has no postgres client either. - `> /media/backups/…` — `/media` is a named volume mounted inside the app container, not a host path, and nothing ever creates a `backups` subdirectory. - `rsync /opt/eventsnap/media/` — that path does not exist anywhere. - "a single path to back up" — false, and dangerously so: exports were moved to their own `exports_data` volume precisely so a keepsake (which contains every photo in the event) can't be served off the media tree. Backing up only `media_data` silently loses every generated keepsake. Rewritten as three commands — db via `docker compose exec -T db pg_dump`, and one `docker run … tar` per volume — all verified against the running stack. The volume mounts use `/src`, not `/media`: I hit the footgun while testing this. Docker pre-populates an EMPTY volume from the image's own directory and chowns it to match, so `-v media_data:/media alpine` tars alpine's cdrom/floppy/usb, writes them into the volume, and leaves it root-owned so the non-root app can no longer write. Mounting where the image has nothing avoids all of it. Documented inline so the next person doesn't rediscover it. Also correct the architecture notes: `/media/*` no longer routes to the backend (that static tree was removed as a gating bypass), and `exports_data` was missing from the volume list — the one volume an operator most needs to know about. e2e stack: add the `EXPORT_PATH` + `/exports` volume it was missing. The file says "mirrors production layout"; without these, exports landed on the container's writable layer at the default path, so export-leak and export-video wrote real archives into ephemeral storage and the "exports live outside media" invariant was never actually exercised. Pre-existing red test, unrelated to the audit: all four 02-upload/quota tests have been failing since 4464147 "stop /me/quota leaking raw disk to guests" (2026-07-19), which post-dates the spec's last edit. `setLimitTo` calibrated `quota_tolerance` from `free_disk_bytes` read through the GUEST's token — a field that commit deliberately zeroes for non-staff. Dividing by it yields a NaN tolerance, so every test in the block died in the helper. Read the calibration inputs through a staff token and keep reading the ceiling back through the guest, whose limit is the thing under test. ──────── test(e2e): document why WebKit can't run the client-queue upload tests Three 02-upload tests have been failing on `webkit-iphone` on main — `02-upload` was already in that project's testMatch, so this is pre-existing red, not something the audit work introduced. Root cause is the harness, not the app. Playwright's Linux WebKit build cannot store Blobs in IndexedDB at all: `put()` fails with "UnknownError: Error preparing Blob/File data to be stored in object store". Confirmed it is not about how Playwright delivers files — a Blob constructed in-page with `new Blob([bytes])` fails identically, while Chromium stores both that and a `setInputFiles` File without complaint. That breaks every test driving the composer (FAB → UploadSheet → /upload → submit), because `handleSubmit` awaits `addToQueue`, which persists the file before it can navigate. The symptom is a submit button stuck on "Wird hochgeladen…" and a timeout waiting for /feed — which reads like an app hang and cost real time to run down. Skip those four (the three above plus the new rejection-visible) on WebKit only, behind a named helper carrying the full explanation, so the next person gets the answer instead of the investigation. Deliberately narrow: WebKit still runs every API-driven upload test, all of 01-auth, 03-feed and 06-export — including the keepsake download, which only WebKit can meaningfully verify. Chromium continues to run all 14. Worth being explicit, since these tests exist to protect iOS: real Safari supports Blobs in IndexedDB, so this is NOT evidence that the offline upload queue is broken on the platform. It does mean that guarantee is currently unverifiable in CI and rests on Chromium coverage plus manual device testing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 19:14:37 +02:00
MechaCat02	3fb1b5d80d	feat(comments): hide every comment mention when COMMENTS_ENABLED=false ... The kill-switch previously left comment UI/text visible in several places. Sweep the whole surface so a comments-off instance shows no trace: Frontend (main app): - VirtualFeed grid tile: gate the comment button/count on $commentsEnabled (was ungated — the only feed surface still showing it). - admin stats: hide the "Kommentare" count card. - UploadSheet "Uploads geschlossen" notice, host ban-modal description, and host/admin unban confirmations: drop the "…und kommentieren" wording. - export page: drop "Kommentaren" from the keepsake description. Keepsake export (had no concept of the flag): - export.rs: thread comments_enabled into the exported data (ViewerEvent), wired through spawn_export_jobs/recover_exports and their call sites (host.rs, main.rs). - export-viewer: gate comment counts (list + grid) and the lightbox comments section; older exports without the field default to enabled (?? true). Backend still 403s comment writes when disabled (unchanged) — this is the UI half so stale clients and archives match. Verified on the running stack (COMMENTS_ENABLED=false): /event reports comments_enabled=false, a regenerated keepsake embeds "comments_enabled": false with no comment UI, and the uploads-closed notice renders "…ansehen und liken." Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 18:26:59 +02:00
MechaCat02	5009590882	feat(diashow): guarantee all eligible photos shown + 2048px display derivative ... Diashow completeness rewrite so every eligible upload is shown regardless of bursts, disconnects, or library size: - queue.ts: SlideQueue with live/shuffle queues, allKnown map, recentlyShown ring; merge(dedup, live-first), remove/removeByUser (prunes recentlyShown), knownIds for reconcile-eviction. Adds queue.test.ts (burst/completeness/race). - diashow/+page.svelte: reconcile (full paginate + evict, pre-scan snapshot to spare concurrent uploads) on mount/reconnect/periodic; catchUpNew paginate- until-known for bursts with debounced maxWait; hard-cut removals; decode timeout + candidate fallback + bounded skip so a broken image never stalls. New ~2048px "display" derivative for big-screen sharpness, decoupled from the data-saver preview (800px) used on phones: - migration 016: upload.display_path + v_feed rebuilt (DROP+CREATE, not REPLACE, to slot the column beside preview/thumbnail). - compression: generate_image_derivatives emits preview+display (downscale-only guard, no upscaling); backfill_missing_display regenerates on startup (safe: logs on error, never soft-deletes). - upload.rs/main.rs: GET /upload/{id}/display (mirrors preview auth/cache), /media/displays direct-serve blocked. - feed.rs + types.ts: display_url in feed/delta DTOs. - diashow candidate chain: display -> original -> preview. Verified on the running stack: migration applied, 10/10 existing images backfilled (2048px cap honoured, small images not upscaled), /display serves 200, /feed returns display_url, diashow cycles. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 17:53:53 +02:00
MechaCat02	4026648f98	fix(diashow): working transitions + slide/push, fullscreen, activity controls ... Transitions never actually animated: Svelte scopes @keyframes names but does NOT rewrite animation references in inline style attributes, so the inline 'animation: crossfade-in ...' never matched its scoped keyframe — a hard cut, no fade (Ken Burns' zoom was dead too). Move the animation into scoped classes and pass dynamic values via CSS custom properties. - Real two-layer crossfade: hold the outgoing frame opaque beneath the incoming one (which is decode-gated), so there's no black flash and no decode pop. - New slide transitions (from below/left/right) as one reusable component; the previous frame is pushed off the opposite edge in step (a conveyor/push), easeInOutSine 1s. - Fullscreen toggle button (Fullscreen API) + 'f' shortcut; Esc in fullscreen no longer also navigates away. - Controls now reveal on pointer/keyboard activity and fade when idle (cursor hides too) instead of being always visible. - wakelock: null the sentinel on the OS 'release' event so re-acquire-on-visible actually fires (previously the screen could sleep after the tab was first hidden). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 15:22:15 +02:00
MechaCat02	44641473ea	fix(quota): stop /me/quota leaking raw disk to guests ... The per-user quota widget was shown to everyone and the /me/quota payload returned free_disk_bytes (raw server free space) and active_uploaders to any authenticated guest. Gate the widget to staff (host/admin) on the upload and account pages, and zero the server-wide telemetry fields for non-staff in the handler. Guests still get their own used/limit so enforcement stays transparent. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 15:22:03 +02:00
MechaCat02	57a907eca5	feat(theme+comments): runtime colour theme and COMMENTS_ENABLED switch ... Colour theme is configurable at runtime from two seed colours (brand + accent); neutrals stay fixed for contrast safety. Tailwind v4 var()-based tokens let a :root:root override recolour everything with no rebuild; the 50->950 ramps are derived via a color-mix ladder. Config lives in the DB config table (admin UI: Config > Farbschema, presets + custom pickers + live preview), served on the public /event endpoint with env defaults (THEME_PRESET/PRIMARY/ACCENT), propagated live via event-updated SSE, and cached in localStorage for a no-flash boot. The keepsake export mirrors the same ladder in Rust so offline archives match the event theme. COMMENTS_ENABLED (env, default true) is a boot-time kill-switch: the backend rejects new comments with 403 and the frontend hides the comment button (feed card) and panel/composer (lightbox). Existing comments stay in the DB, hidden, and return when re-enabled. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 15:21:55 +02:00
MechaCat02	3c3a7d0082	fix(diashow): open SSE on mount; raise upload rate 10→100/hour ... diashow only subscribed to SSE events but never called connectSse(), so a kiosk/projector opening /diashow directly (not via /feed) never opened the EventSource — the showcase display got a one-time /feed snapshot and no live updates, showing "Noch keine Beiträge" forever when turned on before any photos. Open the stream in onMount (idempotent) and close it in onDestroy, mirroring the feed page. Raise the default upload_rate_per_hour from 10 to 100 (migration 015, scoped to installs still on the old default so admin overrides are preserved). Guests routinely upload bursts of 10-20 photos; the old default throttled the first burst. Also update the code fallback and the test-mode reseed. Both verified end-to-end against the docker test stack. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 17:29:08 +02:00
MechaCat02	3654aca18b	feat(export): single-file offline keepsake viewer + guest download ... Rebuild the guest "keepsake" (offline HTML gallery) so it renders when the extracted index.html is opened over file://. Browsers block external ES-module scripts and fetch() at origin null, so a normal multi-file SvelteKit build shows a blank window. Build the viewer as one self-contained index.html (inlined JS/CSS via vite-plugin-singlefile, standalone non-SvelteKit entry) and inject the data as window.__EXPORT_DATA__; the backend embeds the built viewer via include_dir! and writes the data global into index.html when zipping. Also surface the guest-facing download: a feed banner and the BottomNav Export tab, both shown once the host releases the export. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 17:28:54 +02:00
MechaCat02	f243bfe89a	feat(ui): elegant wedding white/silver/gold redesign ... Reskin the whole app via design tokens in tailwind-theme.css (remapped color ramps) plus a define-once component layer in lib/styles/components.css (.btn, .card, .input, .chip, .badge, .sheet, …). Buttons are muted/outlined gold rather than flat fills. Self-host Inter + Fraunces (woff2) under the existing font-src 'self' CSP. Restyle the shared components and the account, admin, host, join, recover and upload screens against the new tokens. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 17:28:42 +02:00
fabi	15d338eeb8	fix(frontend): render client-side (ssr=false) to close pre-hydration interaction races ... EventSnap is a client-only SPA: auth is a localStorage JWT and every page fetches its data in onMount, so SSR only ever produced a logged-out skeleton — including interactive controls that exist in the DOM before hydration attaches their handlers. Interacting in that window silently no-ops: a caption typed on /upload never reaches the reactive state (so cancel() navigates away instead of confirming), and a click on /account's custom role=radio / leave button does nothing. This surfaced as a ~1-4% mobile e2e flake and is a real (if brief) bug for users on slow connections too. Disable SSR app-wide (csr stays on). The server now ships a ~2.5 KB shell with no page controls, so the pre-hydration window is structurally impossible. No SEO is lost (private, QR-gated app). app.html paints a themed boot spinner to cover the JS-load gap (script-free; inline <style> is CSP-safe via style-src 'unsafe-inline'); the root layout's onMount removes it once the app paints. Also fixes the one regression ssr=false exposed: /recover's back chevron used `cameFromApp = from !== null`, which assumes SSR semantics (cold load => from is null). In CSR mode the initial navigation reports a non-null `from`, sending history.back() to about:blank. Key on `type !== 'enter'` instead — SvelteKit's initial-load marker in both SSR and CSR modes. Verified: desktop 210 passed, mobile 22 passed, back-chevron 10/10, frontend gates green (svelte-check 0 errors, eslint, prettier, vitest 46). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-16 21:15:14 +02:00
fabi	f8cba95e49	chore(frontend): add ESLint + Prettier; fix real findings; format the tree ... The frontend had no JS/TS linter — only svelte-check. Add flat-config ESLint (typescript-eslint + eslint-plugin-svelte) and Prettier (tabs/single-quote, matching the existing style). Rules encode "catch bugs, not enforce taste": - svelte/require-each-key KEPT — it is the exact bug class as the feed mis-tap fix. Fixed every flagged block: keyed activeFilters, filteredUsers, stagedFiles (by previewUrl), captionTags, admin tabs/jobs/users, the export-viewer suggestions/filters/comments, and the static skeleton loops. - svelte/prefer-svelte-reactivity KEPT — inline-disabled only the verified-safe sites (a local freq Map in a $derived.by, throwaway URLSearchParams query builders), with a reason each. - svelte/no-navigation-without-resolve OFF — wants resolve() around every goto()/href; taste, not a bug, and pure churn. - svelte/no-unused-svelte-ignore OFF — those comments are consumed by svelte-check, which ESLint can't see, so it wrongly calls them unused; removing them would reintroduce a11y warnings. - no-explicit-any OFF for *.test.ts only (partial fixtures legitimately use any). Real code fixes beyond keys: removed a dead jobLabel(), an unused ViewerComment import and unused catch binding, an unused scroll-lock arg, and replaced an empty interface with a type alias. Then `prettier --write` (54 files). Formatting only. Verified: eslint clean, svelte-check 0 errors, vitest 46 passed, vite build succeeds. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 20:45:42 +02:00
fabi	02971f3186	test(e2e): de-vacuum security tests; add quota, authz-sweep, keepsake-regen coverage ... An audit found tests that pass on broken code. The dominant pattern: fire a security assertion at the all-zeros UUID and accept [403, 404] — the 404 comes from the resource LOOKUP, not the guard, so the guard can be deleted and the test still passes. Repaired to use real resources and demand exactly 403: - banned-user cannot like / comment (the only coverage of those ban invariants) - host cannot promote a real guest (or self) to admin — asserts nobody's role changed - IDOR comment-delete already used a real resource; kept Also inverted recovery.spec's "unknown name → nicht gefunden" test: that asserted the exact account-enumeration oracle the F4 fix removed, so restoring the vuln would have made it pass. Now: an unknown name must be byte-identical to a wrong PIN. New coverage for paths that ran in production but in zero tests: - quota.spec.ts: storage quota enforcement (413 over-limit, atomic increment under two uploads held mid-body so both carry a stale total=0 — the real race; a naive Promise.all version was itself vacuous and is documented as such). Proven to fail without the guard. - authz-sweep.spec.ts: table-driven guest→403 / host→403 over ALL 19 privileged routes + anonymous + __truncate. No live hole found; the whole surface is now locked. - ban / unban / host-comment-delete AFTER release regenerate the keepsake (data-loss paths that were dead under test); comment-delete mid-build doesn't strand the ZIP. Lower-severity de-vacuuming: 10 MB comment test hit Caddy's 502 before the real 500-char cap (now seeds a real upload, 501→400 / 500→201, mutation-verified); XSS name payloads shortened under the 50-char cap so they actually store+render; ui-rendering XSS test now proves the payload rendered before asserting no <b>; export page-object locators fixed to the real "Download" label with a positive empty-state anchor; avatar palette spread test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 07:26:40 +02:00
fabi	c229b560d8	fix(feed,host): two mis-tap bugs where a live re-render destroys the click target ... Both are the same class as the autocomplete bug fixed in bf68bc0: a handler must never destroy the DOM node that is being clicked. feed grid tiles: VirtualFeed keys tiles by upload.id but slices the uploads array POSITIONALLY (`uploads.slice(i*COLS, …)`). A `new-upload` SSE prepends to the array, so every tile shifts one slot and each row's keyed {#each} sees a new set of ids — Svelte destroys and recreates the tile nodes. At a party, where photos stream in continuously, a guest mid-tap can have the node torn out (tap swallowed) or, worse, like/open a DIFFERENT photo that slid under their finger. Grid now buffers live arrivals behind the existing "neue Beiträge" pill; list view is keyed at the top level and stays live. host rebuild button: it lived inside an SSE-driven {#if exportGenerating}{:else if exportReady}{:else} block, and rebuildExport() makes the backend broadcast export-progress immediately — so pressing it flipped the branch and unmounted the button mid-click, on the one screen whose purpose is recovering a broken keepsake. One button now stays mounted across all three states; only its label and disabled vary. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 07:25:19 +02:00
fabi	bf68bc08f4	fix(feed): commit filter suggestions on click, not mousedown ... The `filter-search` spec was flaky (~3%: 5 failures in 180 runs), always as "element was detached from the DOM" while clicking a suggestion. It was not a test bug — it was reporting a real defect. `selectSuggestion` sets `showAutocomplete = false`, which unmounts the dropdown, so a suggestion button DESTROYS ITSELF when activated. It was wired to `onmousedown` — the first event of the click sequence — purely to beat the input's `onblur`, which would otherwise close the dropdown before a click could land. So whether the node survived to `mouseup` depended on whether Svelte's flush happened to fall between the two events. Under load it did, and the click was lost. That is also a real user-facing bug: because it committed on PRESS, sliding off a suggestion you didn't mean to hit still applied the filter, with no way to abort. Fixed the standard combobox way: preventDefault on the dropdown's mousedown suppresses the blur, which is the only thing onmousedown was buying — so the handler moves to `onclick`, the LAST event, where self-destruction is harmless and press-then-slide-off aborts like a button should. Because the input now keeps focus across a selection, `onfocus` no longer re-fires, so reopening is also wired to click/input — without that the picker could not be reopened without clicking away first. Also freezes the suggestion SOURCE while the dropdown is open. `allTags` is ordered by frequency and derives from `uploads`, which every `upload-processed` SSE replaces via refreshFeedInPlace — so an arriving photo could REORDER the open dropdown under the user's finger. At a party, where photos stream in continuously, that is a live mis-tap hazard. This was NOT the cause of the flake (I first believed it was; a clean 60-run said so and a 120-run refuted it), but it is a genuine defect on the same interaction, so it stays. Verified: 240/240 consecutive passes on the previously-flaky spec (baseline 2.8%, so ~0.1% odds of luck), full suite 162 passed / 1 skipped with zero failures. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-14 22:06:56 +02:00
fabi	3c683247c0	chore(deploy): expose the export rebuild hatch in the UI; rehearse migration 014 ... Three deploy-readiness gaps, none of them in the export invariant itself. 1. The escape hatch was unreachable. `POST /host/export/rebuild` was added as the fix for "a failed export is terminal", but nothing in the frontend called it — so recovery required a terminal, the API docs and a valid JWT. The host page instead told the host to reopen uploads and re-release, which is the destructive act the endpoint exists to avoid (it unlocks the gallery to every guest and retracts the release). The failed state now offers "Erneut versuchen"; a ready keepsake can be rebuilt behind a confirm, since a rebuild makes it briefly undownloadable. 2. Migration 014 had never been run against anything. It is the repo's first destructive migration and its backfill has to carry the old notion of "downloadable" across exactly — get it wrong and a released event's keepsake silently 404s, on data that cannot be re-created. backend/scripts/rehearse-014.sh proves it on a throwaway postgres, against a real pg_dump or a synthetic DB covering every pre-014 state, asserting up, down and up-again all preserve downloadability. Verified non-vacuous: retiring nothing (ELSE -1 -> ELSE e.export_epoch) fails it, naming the three keepsakes it would resurrect. It also surfaced that the down migration is an inverse UP TO DRIFT: a ready flag that disagreed with its job row comes back FALSE. That heals corruption rather than restoring it, and costs nothing (no file_path to serve), so the assertion checks what actually matters — no genuinely downloadable keepsake loses its flag — and reports the normalisation instead of failing on it. 3. No advisory scanning. cargo audit + npm audit, in .github/workflows/ because Gitea Actions scans it too and e2e.yml already resolves actions/* from GitHub. The runner is not assumed to have cargo. RUSTSEC-2023-0071 (rsa/Marvin) is ignored SPECIFICALLY, not globally: it is unreachable here (HS256 + bcrypt, Postgres only) and unpatched, so failing on it would mean a permanently red pipeline everyone learns to ignore. Tests: e2e pins that a failed keepsake recovers via rebuild while the event stays released and uploads stay locked — so a future refactor implementing rebuild as an internal reopen+re-release fails — and that rebuild cannot publish an unreleased gallery. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-14 21:09:53 +02:00
fabi	9666d74a46	fix(export): close all 13 findings from the multi-agent review ... A 6-lens multi-agent review (103 agents; every finding adversarially verified by three refute-by-default skeptics) confirmed the epoch redesign is sound — the core invariant holds — and found 13 real defects around it. All are fixed here. The redesign's invariant was re-verified and stands: an accepted upload is always in the keepsake, and a downloadable keepsake always reflects the most recent release. But a WEAKER adjacent invariant did NOT hold — "a downloadable keepsake reflects the current content" — and that is the theme of the biggest fixes. CONTENT REMOVAL NOW ALWAYS REACHES THE KEEPSAKE Regeneration was wired only to host deletes. Ban, unban, guest self-delete and guest comment-delete did not trigger it — yet the export query filters `is_banned = FALSE`, so the pipeline already agreed that content must not be there. Ban someone for abusive content after release and every guest kept downloading an archive containing it. All five removal paths now invalidate and rebuild. `query_comments` also gained the banned/hidden filter it was missing entirely (the ZIP had it; the viewer did not). Each removal is now ATOMIC with its invalidation (one tx, models made executor-generic). Previously the delete committed in its own tx and the regeneration in a second: a dropped handler future between them left the taken-down photo permanently downloadable, and nothing could notice — the keepsake still looked complete and the host could no longer even find the upload to retry. NO MORE TAKEDOWN STORM Every removal spawned two uncancellable full exports. A superseded worker was INERT, not STOPPED: it still ran every ffmpeg spawn and image resize and wrote a whole archive before discovering it had lost. Five deletes left ten workers alive, each holding a full-gallery-sized temp, in a 1 GB container. Now: a debounce before `claim_job` (a superseded worker fails its claim and does ZERO work, collapsing a burst into one export), plus `update_progress` — which already ran exactly the right liveness predicate and threw the answer away — returning it so both file loops bail the instant they are retired. Moderating a comment no longer rebuilds the multi-GB ZIP either: the ZIP is media-only, so it is carried forward, with prune taught to protect any file a live row still references. AN ESCAPE HATCH A failed export was terminal at runtime: release_gallery refuses an already-released event, recovery only runs at boot, and there was no retry route — the only outs were restarting the container or reopening uploads to every guest. Added POST /host/export/rebuild. Also widened mark_failed's guard to `status IN ('running','pending')`: when claim_job itself ERRORED, the row was still `pending`, so the failure was never recorded and the job sat at 0% forever. SILENT INVALIDATION Retiring the epoch 404s the download instantly, but nothing told the clients — guests kept seeing an enabled download button through the whole rebuild. Now broadcasts an invalidation. And the download was a top-level <a href>: a 404 (or a 429 from the per-IP export limit that everyone on the venue WiFi shares) NAVIGATED THE USER OUT OF THE PWA onto raw JSON. It now targets a hidden iframe, so an error response is harmless. ALSO - The HTML export still had the exists()-then-open TOCTOU the ZIP path was fixed to remove, at three sites, two with a hard `?` that failed the ENTIRE viewer. It is reachable: the compression worker hard-deletes an original when a transcode fails and can still be running when the gallery is released. - Crash-orphaned .tmp files were immortal (prune deliberately skips .tmp). Swept at boot, where it is unambiguously safe. - export_status read the epoch in one statement and used it in the next; now one query. - DiskCache::snapshot IGNORED its path argument on a cache hit, returning whatever filesystem was measured last. Latent only because both callers pass media_path — it would have silently misreported the moment anyone measured the exports volume. Now keyed by path. - Corrected two comments that asserted safety properties the code does not have (claim_job does NOT prevent a retired-epoch claim — retirement is enforced at READ time; and a multi-replica reap is NOT contained, it can corrupt the keepsake). Added a rollback runbook to migration 014, the repo's first destructive migration. TESTS The regression guard for the headline FOR SHARE fix was probabilistic — it could pass on broken code if the interleaving fell the wrong way. It is now STRUCTURAL: the upload is held open mid-body with its pre-flight check already passed, so the release provably lands inside the exact window. Verified 5/5 FAILING (201 instead of 403) with the fix reverted, 5/5 passing with it. Verified: backend 40 tests, svelte-check 0 errors, e2e typecheck clean, e2e 160 passed / 1 skipped on chromium-desktop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-14 20:35:47 +02:00
fabi	9f3712894d	fix(export): pin export workers to a live release epoch; make reopen atomic ... Adversarial re-review of c197b2c found the previous fix both incomplete AND that it introduced a new stuck-state regression. Two independent reviewers flagged the latter. HIGH (data loss, still open after the last fix) — a worker could claim a LIVE seq after a reopen. `claim_job` took any `pending` row. If a reopen landed between `release_gallery`'s spawn and the worker's claim, the row was left pending at the *bumped* seq, so the worker claimed a CURRENT generation and spent minutes exporting a snapshot taken while the event was open and guests were still uploading. On the next re-release (which re-arms `export_released_at` BEFORE it bumps the seq) that worker's finalize and ready-flip both passed their guards, flipped ready on its stale snapshot, and made `enqueue_and_spawn_exports` skip regeneration — silently serving a keepsake missing every upload from the reopen window. The reopen seq-bump did not help: the worker's seq was not stale. Fix: `claim_job` now refuses to claim unless the event is still released. A worker's generation is therefore always born AND finalized inside a single live release epoch. The unclaimed pending row is harmless — the next release resets and re-spawns it. HIGH (regression I introduced in c197b2c) — `open_event`'s event-UPDATE and its export_job seq-bump were two autocommit statements. The first is exactly what re-enables `release_gallery`, so a re-release could slip between them: it spawns a FRESH worker at seq N+1, then our second statement bumps that live generation to N+2, orphaning the worker. Its seq-guarded finalize/fail/flip then all match nothing, the row is stranded `running` with no owner, and the host cannot retry ("bereits freigegeben") — only a process restart recovers it. Fix: both statements now run in one transaction, so the row lock on `event` serializes `release_gallery` behind the commit. LOW - The flip-lost path left its stale archive on disk (asymmetric with the finalize-lost path, which deletes it). If a host reopened and never re-released, no future generation would ever prune it. Now discards `out_path` and still sweeps older gens. - A reopen clears the ready flags server-side, but nothing told the clients: the nav and /export page kept advertising a keepsake that now 404s. Both now refresh on `event-opened` (a superseded worker deliberately emits no `export-progress`). Tests - New: a release broadcasts `export-progress` 100 for both types + one `export-available`. The export SSE had ZERO e2e coverage, and this round made the emit conditional — `/export/status` polling reads the job row, not the SSE, so a regression here would have left every other test green while the live UI silently stopped updating. - New: open ‖ release churn always converges to a consistent, downloadable keepsake. Honestly labelled a STRESS test, not a regression guard: verified it still passes against a deliberately non-transactional build even with ~90 concurrent pairs, so it does NOT cover the atomicity fix (that window is not reproducible out-of-process). - Verified the reopen-supersession test is non-vacuous by empirically reverting the seq-bump — it fails, as intended. Verified: backend 40 tests, svelte-check 0 errors, e2e typecheck clean, e2e 158 passed / 1 skipped on chromium-desktop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-14 07:35:25 +02:00
fabi	df275bbefa	fix(rereview): close export-flip race + queue-dedup reload regression ... Adversarial re-review of the persona-audit + audit-followup rounds (6411747..) found one HIGH and one MED regression plus LOW gaps. All fixed with coverage. HIGH — export stale-keepsake resurrected by an open_event race A reopen landing in the window between a *current* export worker's finalize_job and its ready-flag flip cleared export_released_at + the ready flags but left the export_job row `done` at the same release_seq. The seq-guarded flip then still matched and re-set export_{zip,html}_ready=TRUE on a pre-reopen snapshot; the next re-release read that stale TRUE and skipped regeneration (`if ready { continue }`), serving a keepsake missing every upload from the reopen window — the exact data loss migration 012 exists to prevent. Both ready-flip UPDATEs are now additionally anchored on `export_released_at IS NOT NULL`, so a landed reopen makes the flip a no-op and the re-release regenerates cleanly. MED — queue dedup broke for reloaded items loadQueue rebuilt QueueItems from IndexedDB without copying lastModified, which the new addToQueue dedup keys on. A file re-selected after a page reload / PWA relaunch missed the duplicate check and uploaded twice. Rehydration now carries lastModified (extracted to a pure, tested entryToQueueItem helper). LOW - diashow: clear the upload-processed debounce timer in onDestroy (no stray post-unmount /feed fetch). - USER_JOURNEYS §9.5: document the reconnect-delta ban replay (hidden_user_ids / uploads_hidden_at, migration 013), not just the live user-hidden SSE. - e2e api-client: drop the misleading hide_uploads param from banUser — the backend takes no body and always hides; strip the dead boolean at all call sites. Tests - Extract isReversibleLock (the terminal-403 KEEP-vs-PURGE-blob discriminator) into a pure exported helper + unit tests, so the data-loss-critical branch is covered without an XHR harness. - entryToQueueItem unit tests lock the lastModified-carry regression. - Document the export flip-race guard in the reopen/re-release spec (the sub-ms finalize↔flip interleave isn't deterministically forceable with fast fixtures; covered by the SQL guard + the end-to-end completeness test). Verified: backend 40 tests, frontend 44 unit tests, svelte-check 0 errors, e2e 156 passed / 1 skipped on chromium-desktop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 21:47:44 +02:00
fabi	811c724685	fix(audit-followup): close regressions/gaps from the persona-audit re-review ... Adversarial re-review of the persona-audit commit surfaced two HIGH regressions I'd introduced plus MED/LOW gaps. All fixed: HIGH - Auth privilege escalation: reads are sessionStorage-first, but guest `setAuth` wrote only localStorage — a resident admin token shadowed a new guest login (guest ran as admin on a shared device). setAuth/setAdminAuth now DISPLACE the other store so exactly one identity is resident. Adds unit + e2e regression guards. - Host dashboard: `exportGenerating` used `||`, so a one-half export failure stuck on "wird erstellt…" forever and never showed the re-release hint. Changed to `&&`. MEDIUM - Locked-upload auto-resume was unreliable (`event-opened` has no reconnect replay and SSE is down on non-feed pages) — now also resumes on `feed-delta`, which fires on every SSE reconnect. - Queue-cap eviction could drop a recoverable locked item (parked as `error` with a live blob) — now evicts only `done`/`blocked`. - Host page async-`onMount` leaked SSE handlers if unmounted mid-load — added a `destroyed` guard before registration. LOW - An unparseable 403 body now keeps the blob (reversible) instead of purging it. - `refreshEventState` is sequence-guarded so a late close-refresh can't clobber a reopen. - `/export/status` moved out of the all-or-nothing `reload()` so its failure can't blank the whole host dashboard. Verified: svelte-check 0 errors, 36 frontend unit tests (incl. new displacement guards). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 21:19:51 +02:00
fabi	36fe59caa5	fix(user-flow): persona-audit fixes — ban replay, locked-upload data loss, host UX, admin session ... Follows the perf + security + user-flow work with a role/persona audit (guest, host, admin, projector) and fixes across three review rounds. Highlights: HIGH - Ban now replays on reconnect. A ban isn't a soft-delete, and the `user-hidden` SSE has no replay, so a client that missed it (esp. the unattended diashow) kept cycling a banned user's slides. New `uploads_hidden_at` (migration 013) + `hidden_user_ids` in /feed/delta; feed + diashow evict those users. Applied even on a truncated delta. MEDIUM - Locked-upload data loss: a photo staged offline during a lock/release was purged as a terminal 4xx and lost when the host reopened. New reversible `uploads_locked` error code; the queue keeps the blob and auto-resumes on the `event-opened` SSE. - Reopen after release now warns (ConfirmSheet) that it revokes the published keepsake. - Host "forgotten-PIN" badge updates live (`pin-reset-requested` was broadcast but never in KNOWN_EVENTS / subscribed); host page also refetches on `pin-reset` so a two-host race can't hand out a conflicting PIN. - Ban modal copy fixed (read-only ban, not "session ended"); Degradieren/Sperren/Entsperren hidden on peer-host rows for non-admins (they always 403'd). - Host dashboard shows live keepsake generation progress / ready state + link to /export. - Admin JWT moved to sessionStorage (§11.1) to bound exposure on shared devices. Export generation guard (H1 from the prior round, hardened): per-(event,type) `release_seq` (migration 012) with seq-guarded claim/finalize/mark_failed/update_progress, per-generation temp/final paths, download follows `file_path`, prune only strictly-older generations. LOW: diashow coalesces upload-processed (avoids self-rate-limit); event-closed reconciles galleryReleased; /recover gains a forgot-PIN request + drops a stale cached PIN on 401; delta `>=` tie-break + 429 retry; misc copy/labels. Adds e2e: ban-replay, upload-lock-code, and rewrites export-reopen-rerelease with a data-completeness test. Reconciles USER_JOURNEYS §9/§11. Verified: cargo build clean, 40 unit tests, svelte-check 0 errors, 33 frontend unit tests, 155 e2e passing on chromium-desktop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 21:06:28 +02:00
MechaCat02	641174717c	fix(user-flow): close offline-queue, export, session, ban & realtime gaps ... Comprehensive user-flow review across guest/host/admin roles, then fixes with e2e regression guards. Highlights: - Offline upload queue auto-resumes on reconnect: network errors keep items pending (not error), 4xx are terminal (no infinite retry), quota exhaustion returns a distinct 413; queue cap + dedup. - Export lifecycle: release atomically locks uploads; reopen invalidates and re-release regenerates the keepsake; workers claim their job atomically so a reopen->re-release can't corrupt the ZIP; startup re-spawns interrupted exports. - Sessions slide on activity (no 30-day cliff); JWT expiry deferred to the revocable session row; sign-out-everywhere + revoke-on-PIN-reset. - Ban always hides content (v_feed / find_visible_media / export filter is_banned) but stays a read-only ban per USER_JOURNEYS §10 — sessions are not revoked, read access + keepsake download preserved. - Realtime: server-clock SSE delta cursor; event-closed/opened drive the UI live; feed_delta rate-limited; like returns {liked, like_count} to fix multi-device drift; lightbox live comments; diashow delta backfill. - Forgotten-PIN in-app request flow; simultaneous same-name join returns 409; quota increment is transactional; operator floor. Adds e2e/specs/10-flow-review/ (offline resume, export integrity, deterministic anti-race guard) and updates existing specs for the new contracts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-10 23:05:37 +02:00
fabi	a4b2c5bd1c	fix(security): harden authz, media gating, recover, SSE, deps ... Security audit follow-up. No Critical/High existed; these close the Medium/Low findings. F1 [Med] Host privilege boundary: a host could demote a peer host to guest and then ban / PIN-reset (→ account takeover via /recover) them, because the ban/pin-reset peer guards key off the target's *current* role. set_role now blocks a non-admin from demoting a host. F2 [Med] Moderation now revokes preview/thumbnail access: they are served through visibility-checked aliases (/api/v1/upload/{id}/{preview, thumbnail}) that filter soft-deleted / ban-hidden uploads, and direct /media/previews|thumbnails is 404-blocked. Feed emits the gated URLs; Caddy keeps them privately cacheable (max-age=300, short so moderation revokes promptly — the live feed already evicts cards via SSE). Uses a lean find_visible_media() (paths+mime only) on the media hot path. F3 [Med/Low] npm audit fix: svelte 5.55.1→5.56.4 (SSR-XSS advisories), devalue 5.6.4→5.8.1 (DoS). Prod deps: 0 vulnerabilities. F4 [Low] /recover no longer leaks account existence: unknown display name returns the same 401 as a wrong PIN, and runs a dummy bcrypt verify so timing matches — closing the enumeration + timing oracle. F5 [Low] SSE streams re-validate the session every ~60s and close once it is logged out / expired, instead of running until client disconnect. F6 [Info] X-Content-Type-Options: nosniff set at the app layer on all media responses (defense-in-depth alongside the edge). Tests: new e2e specs for F1 (host cannot demote peer host), F2 (preview gated + 404 after delete + direct /media blocked), F4 (uniform 401). 40 backend unit tests + 182 e2e passing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-08 06:14:00 +02:00
fabi	d6c91974eb	perf(backend): close config/upload/export hot paths + stability fixes ... Performance: - Cache the runtime `config` table in-memory (ConfigCache) with synchronous invalidation on every write (admin PATCH + test reseed). Was re-reading each key from Postgres on every request (~8 round-trips per upload). - Stream uploads chunk-by-chunk to a temp file instead of buffering the whole body in RAM (peak was up to the per-class cap, e.g. 500 MB/video); only 512 sniff-bytes are kept for magic-byte detection, then atomic rename into place. - Cache the media-filesystem disk snapshot (DiskCache, 15s TTL) shared by the quota check and admin stats; drop the discarded System::refresh_all(). - HTML export streams video (and small-image) originals straight into the ZIP via a manifest instead of copying them to a temp dir first (removed the transient 2x disk usage) and drops the double directory scan. - Auth extractor resolves session -> live user in one JOIN (was two queries), touching last_seen_at by token hash. Stability: - SSE: on broadcast lag, emit a `resync` event so the client runs a delta fetch instead of silently losing events; frontend reconciles adds, deletions, and (via an in-place refresh) like/comment counts on visible cards. - Storage quota fails OPEN when the disk can't be read (was a 0-byte limit that locked out all uploads). - Graceful shutdown drains in-flight requests on SIGTERM/SIGINT, bounded by a 10s backstop so open SSE streams can't stall a deploy. - Upload removes the persisted file if the DB transaction fails (no orphaned bytes with no row to reclaim them). Tests: - New pure select_disk() with 5 unit tests (longest-prefix, fallbacks, fail-open). - New e2e export-video spec covering the HTML export's video-streaming branch. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-07 20:26:45 +02:00
fabi	faf7a2504a	fix(audit): restore broken upload pipeline + role-based E2E audit fixes ... A comprehensive role-based E2E audit (guest/host/admin, across browser sessions) surfaced one critical and several smaller issues; this addresses them and hardens the tests that missed them. Critical - The client upload pipeline was fully broken: the IndexedDB v1->v2 upgrade opened a *new* transaction inside the upgrade callback, which throws during a version-change transaction and aborted the whole upgrade, leaving the queue object store uncreated -- so no UI upload ever fired. Reuse the version-change transaction the callback provides, and bump the DB to v3 with a contains() guard so installs already corrupted by the shipped bug self-heal on next load. Re-enabled the previously-fixme'd UI upload E2E test. High / Medium - Event lock is uploads-only again: likes, comments and browsing stay open while the event is locked (USER_JOURNEYS 9.3 / FEATURES) -- it was wrongly freezing social interaction. Updated the event-lock spec accordingly. - get_original now excludes soft-deleted and ban-hidden uploads, and direct /media/originals/** serving is blocked, so a hidden user's originals can no longer be pulled by UUID (all originals go through the checked alias). - The upload handler reads the file field with an early-abort size cap chosen from the declared content-type, instead of buffering the entire body before the size check. Low - unban_user mirrors the ban role guard (a host can no longer unban a host/admin banned by an admin). - reset_user_pin's UPDATE is event-scoped. - Admin login returns and stores a real identity (user_id + display name) instead of a blank session. - The host user list no longer renders target-actions (ban/promote/demote/PIN) on the caller's own row, where the backend always rejected them. - /diashow gains a client-side auth guard like the other protected routes. - The join page shows the event name via a new public GET /api/v1/event. Verified: backend cargo build clean, frontend svelte-check 0 errors, full Playwright E2E suite 144 passed / 1 skipped. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-07 07:28:27 +02:00
fabi	0ed97f45cf	fix(review-2): address re-review — close two blocker regressions + harden tests ... The round-2 re-review (full suite green) found two real defects the passing tests missed, both now fixed and covered: B1 — banned users could still edit/delete their OWN content: edit_upload, delete_upload, delete_comment skipped the is_banned guard that upload/ like/comment got (round-2 removed the global extractor block and missed these three). Added the guard (using auth.is_banned — no extra query). The moderation ban test now asserts 403 on DELETE upload, PATCH upload, and DELETE comment for a banned owner (+ upload survives) — it previously only exercised POST /upload, which is why the gap shipped green. B2 — H3 live-eviction was dead code: 'user-hidden' and 'comment-deleted' were missing from KNOWN_EVENTS, so EventSource never listened and the handlers never fired. Added both. New browser-driven sse-eviction test asserts a hidden user's card actually evicts from an open feed with no reload — the backend-only SseListener checks couldn't catch this. Minor items folded in: - admin dashboard bounces a mid-session-demoted admin to /feed via live /me/context (mirrors the host page) instead of a dead error screen. - feed "new posts" pill cleared on any full refresh (pull-to-refresh no longer strands it). - corrected the stale sse.rs comment (banned users may hold a read-only stream). Verified: backend 35 unit tests; svelte-check 0 errors; e2e 04-host + comment-ui + export-leak 13/13 on chromium (incl. the two new regression tests). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-02 22:45:57 +02:00
fabi	b3d876fa85	fix(review-2): medium/low + docs — config validation, hygiene, doc sync ... - compression_concurrency wired to boot config (state.rs) and removed as a dead admin control. - patch_config gains per-key integer/range validation so numerically-valid-but- nonsensical values (-1/NaN/3.5) are rejected instead of silently reverting to default at read time. - clearAuth now also clears the display name (shared-device residual). - e2e/Caddyfile.test mirrors prod security headers + the SSE encode-exclusion so the test stack is representative and can catch header regressions. - .gitignore: ignore root-level Playwright artifacts (test-results/, report). - docs: USER_JOURNEYS §10 and SECURITY-BACKLOG updated to match the implemented read-only-ban behavior and the export-path fix. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-02 22:19:56 +02:00
fabi	80179357a7	fix(review-2): high — read-only ban model, failed-compression cleanup, live SSE eviction ... H1: corrected a round-1 over-reach. Bans are read-only per USER_JOURNEYS §10: the base AuthUser extractor no longer rejects banned users (they keep read access); Require{Host,Admin} and write handlers enforce the ban via auth.is_banned → 403 (incl. self-unban). Demoted hosts still lose powers immediately (live DB role) and are bounced off the dashboard. Also fixed the login/recover redirect regression on unauthenticated 401. H2: failed compression now self-heals instead of leaving a permanent broken card — refund the quota, delete the orphaned original, soft-delete the row; the frontend toasts the uploader and evicts the card on upload-error. H3: self-delete, ban-with-hide (user-hidden), and comment-deletes now broadcast SSE; feed, diashow, and lightbox evict the affected content live instead of waiting for a reload. sse-eviction.spec.ts covers it. Riders: feed/+page.svelte also carries the medium truncated-delta pill; host.rs also carries the low atomic release_gallery claim; admin/+page.svelte also drops the dead compression_concurrency control (medium). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-02 22:19:43 +02:00
fabi	dba4d3f932	fix(review-2): critical — repair comment posting + close export data leak ... CR1: the lightbox comment button POSTed to /upload/{id}/comment (singular); no such route exists, so every UI-submitted comment 404'd and was lost. Fixed to /comments (plural). The prior e2e passed because its seed helper POSTs the API directly — added comment-ui.spec.ts which drives the real component so this can't regress silently again. CR2: export archives (Gallery.zip / Memories.zip / HTML viewer) were written under media_path, which is a public ServeDir — so GET /media/exports/ Gallery.zip served the entire event (every photo, caption, comment, uploader name) to any anonymous visitor at a guessable URL, bypassing the ticket + release gate. Moved exports to a separate EXPORT_PATH (=/exports) on its own volume (Dockerfile chown, compose volume, gated handler reads the new path). export-leak.spec.ts asserts /media/exports/Gallery.zip → 404. Riders (git can't split hunks): LightboxModal also gains H3 live-eviction on comment-deleted/upload-deleted; config.rs also wires compression_concurrency from boot config (medium). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-02 22:19:32 +02:00
fabi	a084ba86c5	fix(review): CSP nonce for FOUC script + feed_delta truncation signal ... Two items surfaced by the branch re-review: CSP regression (blocking): script-src 'self' blocked the template-authored anti-FOUC theme script in app.html — SvelteKit's mode:'auto' only hashes scripts it injects. Added nonce="%sveltekit.nonce%" so it's substituted per request and included in the CSP (survives future edits, unlike a pinned hash). Verified: emitted CSP nonce matches the script tag; no violation, no flash. feed_delta silent truncation: the LIMIT 200 (added earlier to kill the stale-`since` DoS) returned only the newest slice with no signal, so a client that missed 200+ uploads during a reconnect could not tell it should full- refresh — the older missed uploads were dropped and unrecoverable (the next delta advances `since` past them). DeltaResponse now carries `truncated`; the feed's feed-delta handler calls loadFeed(true) to resync from page 1 instead of merging a partial slice. Verified: cargo check clean, svelte-check 0 errors, production build green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 21:51:08 +02:00
fabi	91ff961850	fix(security): medium/low — event-lock, atomic config, a11y, diashow, hygiene ... - social: likes/comments rejected on a closed event (e2e proven). - admin: patch_config validates-then-writes atomically; char-based length. - hashtag/comment models: atomic tag writes in edit + comment paths. - Modal: inert the background (modal-inert action) for screen readers. - sse.ts: idempotent visibilitychange listener (no duplicate reconnects). - diashow: videos advance on `ended` (transitions + page wiring). - docs/hygiene: README clone-case fix; removed stale committed .env.test and gitignored it; docker-compose.dev.yml tidy. Left documented as accepted-risk per plan: PIN-persist-after-logout, UUID-reachable hidden uploads, DECISION-media-auth.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 21:25:58 +02:00
fabi	f08d858281	fix(security): high — live authz, XFF, SSE buffering, atomicity, pagination ... H1: auth extractor re-reads the live user row — trusts the DB role (not the JWT claim) and rejects banned users mid-session. e2e proves a demoted host loses powers and a banned host is locked out and can't self-unban. H2: client_ip takes the right-most XFF hop (the one Caddy appends); spoofed left-most entries are ignored, restoring IP-based throttles. H3: Caddy excludes /api/v1/stream from `encode` so SSE isn't buffered. H4: upload — quota increment + row insert + hashtag links now one txn. H5: feed keyset pagination tiebroken on (created_at, id) + composite index (migration 010); feed_delta bounded with LIMIT. H7: LightboxModal keys its comment load off upload.id, ending the SSE-driven refetch storm. H8: CSP via SvelteKit kit.csp (svelte.config.js) hardens the localStorage token model against injection. Migration 010 also adds the latent comment/comment_hashtag indexes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 21:25:50 +02:00
fabi	74849c8d50	test: cover grid filter OR/AND (extract pure fn + unit + real e2e) ... The two filter-search cases were test.fixme placeholders (expect(true).toBe(true)), so the OR/AND chip rules were untested. - Extract the grid-filter predicate from feed/+page.svelte into a pure filterUploads(uploads, filters) in $lib/feed-filter (behavior-preserving) and unit-test it (9 cases): tag OR, user OR, tag+user AND, AND-excludes-partial, case-insensitive caption match, null caption. - Replace the e2e fixmes with real tests that seed known captions/uploaders, switch to grid view, activate chips via the search suggestions, and count grid tiles: OR widens 1→2, AND narrows 2→1. Frontend unit: 27 passing. filter-search e2e: 3 passing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 20:08:28 +02:00
fabi	226e455328	test(unit): broaden coverage — quota formula + auth token/JWT decode ... Backend: extract the per-user quota formula from compute_storage_quota into a pure `quota_limit_bytes(free_disk, tolerance, active)` (behavior-preserving) and unit-test it: tolerance scaling, floor of fractional results, active<1 clamped to 1 (divide-by-zero guard), zero free disk, single-uploader identity. Frontend (jsdom + browser:true mock): auth.ts token storage and JWT claim decode — setAuth/getToken/getPin round-trip, clearAuth keeps the PIN (for recovery), clearPin, getExpiry (exp seconds→ms Date; null on missing/malformed), getRole (role claim; null on absent/malformed). Adds jsdom devDependency. Backend: 25 passing. Frontend: 18 passing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 19:53:03 +02:00