247 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
MechaCat02	5a33ab460f	fix(copy): five texts that told guests the wrong thing ... None of these are cosmetic — each one either misdescribes the UI or omits something a guest needs to get back into their account. JOIN. "Willkommen bei" + "<Event>" read as "Willkommen bei Hochzeit von …". Adds the article. This deliberately couples the lead-in to EVENT_NAME's grammatical gender and is wrong for "Willkommen bei der Sommerfest" — noted in the markup, with the article-free alternative, for whoever reuses this. The no-name fallback moves from "dem Event" to "Feier", or it would now render "Willkommen bei der dem Event". GUIDE / post actions. Named only the long-press, which is invisible: a guest has to already know it exists to find it. Now names the three-dot button that is on every card in list view — described as "die drei Punkte (⋯)" rather than a glyph, because the icon renders HORIZONTALLY (three circles at cy=12) despite the code comment calling it a kebab. Long-press stays in the text, because the button exists ONLY in the list view: the grid tiles have `use:longpress` and no button at all, so a menu-only instruction would strand anyone browsing in grid mode. "anzeigen und speichern", not "herunterladen" — the action opens the original inline in a new tab (Content-Disposition: inline, deliberate, it is the only playable video source), so the guest saves it from there. GUIDE / recovery. Said "Deinen PIN merken!", but `POST /recover` takes {display_name, pin} — a guest who memorised four digits and forgot whether they typed "Anna" or "Anna M." still cannot get in. Now names both. It also claimed the PIN is "immer unter Mein Konto zu finden", which is false in the only case that matters: /account renders it from local storage and falls back to "PIN nicht gespeichert", so it is NOT on the new device you are trying to reach. UPLOAD / photo-task game. Adds a persistent helper line under the caption box rather than a second placeholder line: a `placeholder` attribute may not contain line breaks (Safari collapses them), and a placeholder disappears exactly when the guest starts typing and needs it. The hashtag is written plain on purpose — `#fotoaufgabe3` is a DIFFERENT tag from `#fotoaufgabe`, so putting the number inside it would turn twelve tasks into twelve unfilterable tags. UPLOAD SHEET. "Öffne den Link in Safari oder Chrome" named a link that is not on screen — the guest is already inside the app. Now names the situation (the WhatsApp in-app browser the join link opens in) and the menu entry that escapes it. Kept rather than removed: in that webview the camera and file picker can silently do nothing, with no error and no operator to ask. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 22:42:13 +02:00
MechaCat02	e3159299c0	test(loadtest): an event simulation on a real 2 vCPU / 4 GB / 30 GB box ... `driver.mjs` is a pipeline benchmark: synthetic images, uniform load, rate limits off, and — the part that mattered — an unconstrained host, so the 1 GB app cap was never exercised and the disk gate never fired. It could not have found either of the two defects fixed in the preceding commits. This harness differs in three ways that earn their keep: REAL CONTENT. Uploads come from a pool of actual wedding photos and videos, unedited, including the HEIC files and 25 MB frames the app is supposed to REFUSE. Those refusals are the test, not noise to filter out — 152 of 932 attempts were refused, and the breakdown of WHY is the most actionable output. PERSONAS. ~100 viewers and ~50 uploaders across nine behaviour profiles, six device profiles, each with a join time and a session length. A casual guest who posts four photos generates a completely different request mix than a photographer dumping 130, and both differ from a kiosk holding one SSE stream all night. A 37-case abuse suite covers malicious payloads, injection, cross-user tampering, enumeration and the rate limiters. RATE LIMITS STAY ON. `driver.mjs` disabled them because it ran every guest from one IP. Almost every limit that matters is per USER, not per IP, and those are as real for 150 synthetic sessions as for 150 phones — leaving them on is what lets the abuse personas prove the defences work. The per-IP limits ARE distorted by the single source address; that distortion is measured and reported rather than configured away. `docker-compose.sim.yml` reproduces the CX22 rather than asserting it: production's per-service cpus/memory/cpu_shares verbatim, every container pinned to the SAME two cores with `cpuset` so they genuinely contend, and a real loopback ext4 volume so the app's own statvfs returns true numbers. Run the driver under `taskset` onto other cores, or the load generator competes with the thing it measures. `browser-check.mjs` covers what an HTTP driver structurally cannot: the SvelteKit container, and whether the frontend ESCAPES the XSS caption the backend stores verbatim. The backend stores captions raw by design, so the renderer is the entire defence — and only a browser can prove the payload is inert. It reports INCONCLUSIVE rather than PASS when the payload never reached the DOM, because a check that renders nothing proves nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> v0.18.0	2026-08-20 22:58:17 +02:00
MechaCat02	464b270716	feat(disk): KEEPSAKE_ENABLED trades the archive for ~3x the usable media ... The upload gate refuses any photo that would leave too little room to build the keepsake, and the archive needs both halves at once — so it demands `2.2 x media + 10 GB reserve + 1.5 GB headroom`. Every gigabyte of photos therefore costs about 3.2 GB of disk budget, and usable media works out at `(disk - 11.5 GB) / 3.2`. On a 30 GB volume that is only ~5.8 GB of photos. Measured, not theorised: a 945-photo wedding (8.74 GB of real files) stopped after ~780 photos with 24.98 GB free — the gate wanted 25.91 GB on a disk that was 79% empty. Uploads ended for want of an archive nobody had asked for yet. `KEEPSAKE_ENABLED=false` drops the archive term, leaving only `DISK_RESERVE_BYTES` — the one question still live without an archive, which is whether Postgres can still write. That turns the same 30 GB volume into ~20 GB of usable media. Verified against the exact disk state that ended the run: the photo that returned 413 with the keepsake armed is accepted with it off. The headroom term goes with it, deliberately. It exists only to keep this gate strictly ahead of the EXPORT PREFLIGHT, and with no keepsake there is no preflight to stay ahead of. Boot-time immutable, like COMMENTS_ENABLED: flipping it mid-event would move the gate under uploads already accepted against the old one. Releasing the gallery and minting download tickets are refused while it is off, and the host dashboard hides the release control rather than offering a button that answers 403 — a new `keepsake_enabled` field on `GET /host/event` carries that. The gate and the host's low-disk banner now share `upload_gate_required_free`. They were already two expressions of one threshold, and the banner exists to fire BEFORE the gate closes; applying the switch to only one of them would warn the host about a limit that can no longer fire, or stay silent past one that can. Tests pin the lead in both modes. The cost is real and worth stating plainly: there is no downloadable gallery at the end, so guests keep only what they save from the feed. Prefer a bigger disk where you can — ~45 GB holds this library with the keepsake intact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 22:57:25 +02:00
MechaCat02	cacf616c2d	fix(upload): a client vanishing mid-commit lost the photo's preview forever ... The compression job is handed to the worker by a bare `tokio::spawn` that runs AFTER `tx.commit()`, and the commit is a suspension point. If the guest walks out of range inside it, Postgres applies the COMMIT and axum drops the future before the spawn is reached: the row lands durably at `compression_status = 'pending'` with no job behind it. Nothing looked at it again. `startup_recovery` rescues only `'processing'`, and `backfill_stale_derivatives` — whose predicate WOULD match — runs once at boot and never on a timer. The photo keeps its feed entry, never gets a derivative, forces every viewer to pull the full original instead, and is skipped by the diashow for the rest of the event. Silent, and permanent. This is the same hazard `TempFileGuard` already covers for the file, reached one line later, so it gets the same answer: an `EnqueueGuard` armed before the commit and stood down only once the job is with the worker. `Drop` runs on cancellation, which closes the window — and it covers the indeterminate-commit error path too, which returns Err on a row that may well be live. Queueing a job for a row that did not commit is harmless: the status update matches zero rows and the task retires. A guard cannot survive a SIGKILL, so `requeue_stuck_pending` sweeps for the same state at boot and every ten minutes. The grace window is what makes it safe to re-enter the live path: a task flips the row to `'processing'` as its FIRST act after taking a permit, so a row still `'pending'` ten minutes on is lost rather than merely queued. The event simulation peaked at 120 queued with a p99 of 97s while being fed thirty times a real event's arrival rate, so the margin is wide. Hit 1 upload in 932 during that run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 22:57:02 +02:00
MechaCat02	94d279fa69	fix(upload): a NUL byte in a caption returned 500 and cost the guest the photo ... Postgres refuses a NUL in a TEXT column outright — `invalid byte sequence for encoding "UTF8": 0x00` — and that arrived here as an anonymous `sqlx::Error`, became `AppError::Internal`, and returned a 500. The photo went with it: the transaction rolls back with the file already streamed to disk, so the guest loses the upload as well as the caption, with nothing in the message telling them why. Only `display_name` was validated for control characters; `caption`, the hashtag CSV and `comment.body` were length-checked alone. Rejected at the edge with a 400 instead, and deliberately narrower than `validate_display_name`: a caption legitimately carries newlines and emoji, and every control character except NUL stores and renders harmlessly, so this refuses exactly the byte that cannot work. Rejected rather than stripped — silently rewriting what a guest wrote is the worse failure, and no real client emits a NUL by accident. Found by the event simulation's abuse suite; it was the only input of 37 that produced a 5xx. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 22:56:45 +02:00
MechaCat02	a7d2df6e9e	fix(icon): tilt the rings so the right band sits above the left ... Rotated -45 degrees about the icon's centre. Negative because SVG's y axis points down, so a positive angle would have dropped the right band instead of lifting it. The transform sits on the group rather than on the individual shapes. The two circles and the arc that redraws the upper crossing are all still authored on the horizontal axis and rotate together, so the interlock geometry did not have to be recomputed and the bands still alternate -- one over at the first crossing, the other over at the second. Re-checked the maskable safe zone, because the bounds recorded for the horizontal artwork no longer describe it: the box is now 102.9-409.1 on both axes, not x 88-424 and y 139-373. The circular crop needed no arithmetic at all -- the farthest painted point stays 168 from the centre (the 51 centre offset plus radius 104 plus half the 26 stroke), inside the 204.8 safe radius, since rotating about that same centre cannot change any point's distance from it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> v0.17.6	2026-08-18 20:11:33 +02:00
fabi	da2d4f67e7	fix(icon): wedding rings, and delete the skeleton favicon behind them ... The event is a wedding, so the camera icon becomes two interlocking bands. Drawn rather than sourced: at 16px in a tab anything finer than the stroke turns to smudge, which is why the camera it replaces was three shapes and no more. White on #8a6a2b, the event's own theme_primary, so the icon, the site and the PWA chrome finally agree -- the manifest's theme_color was still the #2563eb from the camera branding. The rings span x 88-424 and y 139-373 including stroke, inside the centre-80% safe zone, so an Android circle crop cannot clip them. Also removes a second, competing icon declaration. `+layout.svelte` imported `$lib/assets/favicon.svg` -- the orange Svelte logo from the project skeleton, which Vite inlined as a data URI into the layout bundle -- and applied it via `<svelte:head>`. Which of the two won was left to the browser: the link in app.html is parsed from the initial HTML, this one is added at hydration, and Chrome keeps the former. So the skeleton logo did not usually show, but nothing guaranteed that, and `ssr = false` means the branded link is the only one present at first paint anyway. app.html is now the single source and the skeleton asset is gone.	2026-08-18 18:03:31 +00:00
MechaCat02	01e7e2ab1e	Merge branch 'fix/upload-ceiling-diskcache-release-docs' into main v0.17.5	2026-08-17 17:56:53 +02:00
MechaCat02	d270cfcf91	docs(release): the rollback section's facts were wrong, and it is the emergency path ... §6 and §9 both asserted "latest existing tag is v0.12.0". It is v0.17.4 — twelve tags newer — and HEAD is 82 commits past that. Everything built on that premise was therefore wrong at the one moment nobody has time to check it. **The dangerous half.** §9 argued that a rollback to the previous release could not even get off the ground: "No v0.12.0 image was ever built or pushed either, so the pre-pull would fail with `manifest unknown` before you ever got that far." That presents the registry as a safety net. It is not one. Images for the earlier v0.17.x releases may well be resident — and after §9's own T-2 pre-pull step, on the server — in which case the rollback pulls cleanly, starts, and crash-loops on `VersionMissing` (16 migrations against a database carrying 31) behind a live Caddy. That is the exact permanent outage §9 exists to prevent, reached through the one door it said was closed. Rewritten to say what actually decides: the migration set, checked with `git ls-tree`, never the registry. A successful `docker pull` is not evidence. The heading changes from "no older image you can roll back to" to "no released tag is a VALID rollback target" — older images very probably do exist; what none of them has is a schema the live database can boot against. The twin-tag scheme below it was always the right answer and is unchanged. **The version half.** §6 told you to build and push `v0.17.5`... under the name `v0.13.0`, which has existed as a git tag since April and carries 6 migrations. That image would disagree with the tree of the same name, and any host still pinned to that tag silently swaps builds on its next pull. `.env.example` shipped `EVENTSNAP_VERSION=v0.13.0` too, and README used a third number (`v0.13.1`). All three now say v0.17.5 (+ the `-a` rollback twin). **And the commands now reproduce their own output.** The `git tag` invocation this commit first reached for returned `archive/pre-squash-20260729`, not v0.17.4 — the repo carries a non-release tag that sorts first. Both call sites now use `--list 'v*' --sort=-v:refname`, and all three commands in the §9 evidence block were run and produce exactly what the block claims. Verified: `git tag --list 'v*' --sort=-v:refname | head -1` → v0.17.4; `git ls-tree --name-only v0.17.4 backend/migrations/ | grep -c up.sql` → 16; `git rev-list --count v0.17.4..HEAD` → 82. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:54:34 +02:00
MechaCat02	e645d78a6e	fix(disk): the free-space cache stopped caching once a second volume was asked about ... `DiskCache` held ONE slot carrying its own key, so a lookup for a different path was a miss that OVERWROTE the previous reading. The app asks about two paths that are distinct mounts in production: `MEDIA_PATH=/media` and `EXPORT_PATH=/exports`. * the upload gate and the per-user quota ask about the media volume on EVERY photo (`handlers::upload`); * `host::get_event_status` asks about the exports volume on every host dashboard load. So while a host had the dashboard open the two evicted each other and the hit rate collapsed to zero, putting an uncached `sysinfo::Disks::new_with_refreshed_list()` — a synchronous scan of every mount, on the async runtime — back on the busiest write path in the app. That is precisely the cost `handlers::upload`'s own comment says this cache exists to avoid, on the 2-vCPU box it says it matters on, and it degrades hardest exactly when a host is watching the disk because uploads are failing. Correctness was never affected — the slot carried its key, so it never returned the WRONG filesystem's numbers. It missed and re-measured instead, which is the quieter failure and the one that cost. Now one entry per path. The key space cannot grow: both paths come from `AppConfig`, never from request input. `invalidate` clears ALL volumes, since the e2e TRUNCATE moves free space on every one of them and a survivor would let the next test compute against the previous test's disk. Three tests. The one that matters most is `a_stale_entry_is_refreshed_without_ deadlocking`: the hit check holds a READ guard and an expired entry falls through to a WRITE guard on the same non-reentrant `RwLock`, so whether they overlap depends on when the `if let` scrutinee's temporary is dropped — edition 2024 drops it before the fall-through, the 2021 rules did not. Too subtle to leave to a reading of the edition, so it is pinned; it HANGS rather than fails if that ever regresses. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:54:11 +02:00
MechaCat02	8dcc3a7a98	fix(upload): a raised size limit destroyed videos instead of refusing them ... `MAX_UPLOAD_BYTES` (576 MiB) is the router's `DefaultBodyLimit` on the upload route. Its coupling to the admin-tunable `max_image_size_mb` / `max_video_size_mb` was enforced by a COMMENT — "if an admin raises max_video_size_mb above this, bump MAX_UPLOAD_BYTES" — while `patch_config` accepted 1024 and 10240 respectively and the dashboard rendered "Max. Videogröße (MB)" as a bare number field with no stated ceiling. Set it to 1000 and every video between 576 MB and the new limit is not refused, it is DESTROYED, and the shape is worse than the size: * The body limit trips MID-UPLOAD, inside `field.chunk()`, so `stream_field_to_file` maps it to `AppError::BadRequest` — a 400, not a 413 carrying the `quota_exceeded` code the client knows how to keep a blob for. * `classifyUploadStatus` puts every non-401/408/429 4xx in the `terminal` bucket, and `isReversibleLock(400, 'bad_request')` is false — so the queue DELETES the blob from IndexedDB and moves the row to `blocked`, which by design offers no retry button. * All of that after the guest pushed 600 MB over cellular, and the message they get names a read failure rather than a limit. "Raise the video limit" is exactly the change a host makes after a guest complains a clip was too big, so this is reachable by an operator doing the obvious thing. The ceiling is now DERIVED from the body limit rather than written down twice (`MAX_CONFIGURABLE_UPLOAD_MB`, 575) and enforced at both ends, because either alone leaves a hole: `patch_config` bounds what can be WRITTEN, and the upload handler clamps what it READS, since a row stored before this bound existed — or edited straight into the `config` table — would sail past the first check. A compile-time assertion pins both directions against the ACTUAL field caps (`MAX_CAPTION_BYTES + MAX_HASHTAGS_BYTES + MAX_CLIENT_UPLOAD_ID_BYTES` plus framing), so raising `MAX_CAPTION_LENGTH` fails the build rather than silently eating the envelope margin; a lower bound keeps the ceiling clear of the 500 MB `max_video_size_mb` seeded by migration 005. Ordering is now guaranteed: at 575 MiB the handler's own cap trips while the body is ~1 MiB short of axum's, so the clean "Datei ist zu groß" 400 always wins the race against the mid-stream abort. Frontend, both halves of the same rule: * the composer's pre-flight moves from 576 MiB (the raw body limit) to 575 MB, so a guest is rejected locally against the same number the server enforces and never pushes the file to find out; * both size fields gain a hint naming the 575 ceiling, so the operator learns the bound from the form instead of from an error after typing 1000. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:53:56 +02:00
fabi	9759c7c669	fix(ops): the hourly backup never ran, and an unset POSTGRES_USER crash-loops silently ... **The backup that did not exist.** `.env.example` ships `EVENT_NAME=Max & Maria's Wedding` and the runbook tells you to `cp .env.example .env`. Compose's env_file parser reads that fine. POSIX `sh` does not: `. ./.env` aborts with "Unterminated quoted string" (verified, rc=2), and every variable defined after that line is left unset. The §10.2 cron script is `#!/bin/sh` + `set -eu` + `. ./.env`, so it exited before `pg_dump` — every hour, into a log nobody reads. The only automated backup of the one thing the runbook calls irreconstructible produced nothing, and §10.2's own "prove it works NOW" only catches it if `.env` is already final at that moment. The script reads NOTHING from `.env` — `POSTGRES_USER`/`POSTGRES_DB` are expanded inside the db container by the single-quoted `sh -c`. The source line was pure liability and is gone. `EVENT_NAME` is now double-quoted in `.env.example`, which both parsers read identically (verified), and the three interactive sourcing sites now read just `$DOMAIN` instead of sourcing the whole file. The verify step also proves the dump is a non-empty valid gzip containing tables, rather than that a file exists. Also fixes the script's `cd /root/eventsnap`, which contradicts §5's non-root deploy and §13's `~/eventsnap` — under a non-root deploy it failed the same way, silently. **The crash loop with no message.** `docker-compose.yml` interpolated `POSTGRES_USER`/`POSTGRES_DB` with no default and no `:?` guard, into `environment:`, which OVERRIDES `env_file`. Unset does not fall back — it resolves to the empty string, initdb creates a role and database named "", `DATABASE_URL` still says `eventsnap`, and the app hits `FATAL: role "eventsnap" does not exist` forever. `pg_isready -U "" -d ""` never passes, so `app` never turns healthy and Caddy — gated on `service_healthy` — never starts: port 443 dead for the whole event, exit only via `down -v`. Both now carry `:?` guards (verified they fire), and §3's ".env template — ALL of them" list, which omitted both, now includes them. Other runbook corrections: the backup/restore pointer named a line range that had drifted into an unrelated section and stopped mid-restore, before the media restore and the mandatory `chown` — now referenced by heading, which cannot go stale. §7.3 told you to verify that `EXPORT_PATH` is not pinned when §3 correctly says it is. Stale counts: rev-list 196 -> 217, "versions 007–022" -> 007–031, `frontend/Dockerfile:9` -> :8, and the low-disk description now matches the code (the 10 GB absolute floor was removed as unreachable). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 19:46:21 +02:00
fabi	cfc8bd0016	test: replace coverage that could not fail with coverage that can ... `backend/tests/` follows a house rule of copying production SQL character-for- character rather than calling `src/`, because the crate is a binary and nothing in it is importable from an integration test. For pinning behaviour that already existed that is a defensible trade. Applied to a NEW fix whose only coverage is the copy, it proves nothing: the fix and its test become two independent implementations, and deleting the fix leaves the test green. `audit_names.rs` did exactly that. It never called `audit::record` — it reimplemented `resolve_names` and the INSERT inside the test file, down to a hardcoded `.bind("host")`, and then asserted `actor_role == "host"` against its own literal. That assertion could not fail for any change to the code it named, and grep confirmed there was no other coverage of the audit-name work anywhere. Moved into `#[cfg(test)]` inside `services/audit.rs`, where the real function IS callable. CI already runs `cargo test --all-features` with a live DATABASE_URL, so `#[sqlx::test]` works there; verified all four run and pass. The role assertion now compares against `UserRole::as_str()` itself rather than a literal, so it tracks a rename instead of pretending to, plus an explicit `assert_ne!` against the Debug spelling. Also: - `retry-after-release.spec.ts` filtered the feed on `u.id === original.id` to prove "no second row was created". A duplicate gets a fresh uuid and could never match, so the filter yielded exactly 1 whether the gallery held one copy or five. Counts by uploader now, with the original's identity asserted separately. (The rest of that spec is sound — its 403 control and replay-id check both fail if the header fast-path is reverted.) - `upload_after_release_commits_sees_the_lock_and_is_rejected` claimed the handler answers `UploadsLocked`. It answers `GalleryReleased` since the check order was inverted on this branch, and the test asserts no variant at all. Documented what it actually covers (the locked READ) and where the ordering IS covered (two e2e specs). - Two `// SRC:` pointers had drifted ~130 lines into unrelated code, which is how a hand-copied fixture silently stops matching its original. Now named, not numbered. - `emptyOutDir: false` claimed a failed viewer build "leaves the last good artifact in place". True for the `generateBundle` error, false for the newer `writeBundle` assertion, which fires after Vite has already written the file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 19:46:04 +02:00
fabi	ee70eec094	fix(frontend): three dead ends a guest cannot get out of ... **1. The cached PIN could never be cleared after a host reset.** `/recover` clears a rejected cached PIN only when the submitted name is the one this device belongs to — narrowed on this branch so a guest who mistypes their own name does not lose the only copy of their PIN (the server keeps just the bcrypt). But it compared against `DISPLAY_NAME_KEY`, which `clearAuth` deletes for shared-device privacy — one step BEFORE the guest ever reaches that screen: host taps "PIN zurücksetzen" -> the backend also revokes every session for that user -> the guest's next request 401s -> clearAuth -> redirect to /join -> they go to /recover, where the field is pre-filled with the dead PIN and the guard can never fire again Since a 4-digit value auto-submits, every correction burns another of the four wrong-PIN attempts the shared venue IP allows per 15 minutes. The PIN's owner is now stored WITH the PIN and survives alongside it, with a fallback to the auth display name for devices that cached a PIN before this key existed. **2. Every layout-level SSE handler waited on the `/me/context` retry.** The retry was awaited inside the same `onMount` that registers `pin-reset`, `user-hidden`/`user-shown`, `event-closed`/`event-opened` and `event-updated`. Worst case is a 20s timeout + 2s backoff + a second 20s timeout: ~42s with an empty handler list, on exactly the wifi the retry exists for. Five of the six self-heal; `pin-reset` does not, and a missed one leaves a dead PIN displayed in "Mein Konto" and pre-filling /recover — the same state as (1), reached from the other end. Detached, since nothing below reads its result. **3. `crypto.randomUUID` was on the join critical path.** It needs Safari >= 15.4 / Chrome >= 92 AND a secure context. The queue already depended on it, so an old phone previously joined and browsed and only failed at upload — degraded but survivable. Minting an idempotency key at join turned that into a `TypeError` caught by the generic handler and rendered as "Ein Fehler ist aufgetreten." on every retry: cannot join, cannot browse, and /recover is no help because there is no account yet. The one screen where a hard failure has no way out at all. Falls back to `crypto.getRandomValues` with the RFC 4122 version and variant bits set; `Math.random` is deliberately NOT a further fallback, since a collision between two guests would replay one guest's join or upload onto another. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 19:45:46 +02:00
fabi	9bae5d77ed	fix(join): concurrent first joins no longer 500 on the QR-scan burst ... `Event::find_or_create` was check-then-insert against a UNIQUE slug, and its only callers are `/join` and `/admin/login` — both of which run before the row exists, at the single most concurrent moment the app ever sees: the QR code goes up and every phone in the room posts `/join` within the same second. All of them miss the SELECT, all of them INSERT, one wins, and the rest get a bare unique violation surfaced as a 500 on the very first screen of the event. There is no retry on that path and nothing in the UI explains it. In the documented timeline the host's T-5 admin login creates the row first, so the blast radius is small — but it is one `down -v` or one `EVENT_SLUG` edit away from being live on the night. `ON CONFLICT (slug) DO UPDATE SET slug = EXCLUDED.slug` — a deliberate no-op write, because `DO NOTHING` returns no row on conflict and would put the loser back at square one. It touches only `slug`, so `name`, `export_epoch` and the lock/release timestamps are never disturbed by a late arrival; a test pins that. The read fast-path stays, so every join after the first is still a plain SELECT and takes no row lock. Tests live in `src/` rather than `tests/` because the crate is a binary and the function is not importable from an integration test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 19:45:32 +02:00
fabi	20c15c3500	fix(backend): three ways the end of the night could go wrong ... **1. Releasing the gallery could arm the keepsake with no worker.** `release_gallery` ran `tx.commit()` -> SSE `event-closed` -> `audit::record().await` -> `spawn_export_jobs`. The audit write is two pool round-trips, each able to wait the full 5s acquire timeout, and it runs in the same instant `event-closed` fans out to ~100 phones whose upload queues all hit the API at once. Axum drops the handler future when the client disconnects — the host taps "Freigeben" and pockets the phone. The release has COMMITTED: event closed, uploads locked, epoch bumped, both `export_job` rows pending, and no worker. `/export/*` 404s, the page sits on "Wird vorbereitet…", `recover_exports` only runs at boot, and a second release is refused. Every other regen call site spawns first; `me.rs` says so in a comment. This was the sole violator, and the only path that arms the FIRST build of the keepsake. Spawn moved immediately after the commit. **2. The event could be left with no operator.** `remaining_operators` was an unlocked pool COUNT followed by a separate UPDATE, so `ban_user` and `set_role` raced each other and `DELETE /me`: an admin demotes host B while host A deletes themselves, each check sees the other still present, both commit, and nobody can moderate, release the gallery, or appoint anyone — appointing requires being an operator. The count now runs inside the writing transaction behind the same advisory lock `delete_account` uses, via one shared helper so the key cannot drift between copies. The lock is taken FIRST in all three, and the order is load-bearing: `delete_account` previously took it last, after row locks on `upload` and `event`, while the two new call sites take it before locking those same rows — an ABBA that Postgres would resolve by killing one transaction with a 500. The ordering rule is documented on the helper. **3. The keepsake could become unbuildable the moment uploads stopped.** The upload gate and the export preflight computed the IDENTICAL threshold (`required_free_bytes(media, 2) + DISK_RESERVE_BYTES`), leaving zero margin between them. Once the gate refused its first upload the preflight was already at its own limit, so anything written afterwards decided the keepsake's fate: WAL up to `max_wal_size`, 30 MB x 4 of container logs, and the compression backlog draining at exactly that hour. The release commits before the workers bail, so the failure lands at 01:00 with no second release possible. The gate now demands `UPLOAD_GATE_HEADROOM_BYTES` more than the preflight, costing ~0.5 GB of media ceiling — the trade README already argues for. The dashboard banner mirrors the new threshold so its lead is unchanged, and a new test pins gate-before-preflight at six gallery sizes. Also: the global disk gate fails OPEN when the mount cannot be read, which is deliberate, but did it SILENTLY — no log line at all, while the export preflight warns on the identical condition. Inside a container `/` is an overlay rather than a `/dev` device, so this is reachable, and when it happens the only global disk bound is gone and the box fills until Postgres cannot write WAL. README's sizing table was also arithmetically self-contradictory (it showed ~27 GB free against a ~27.6 GB requirement); recomputed for the new gate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 19:45:24 +02:00
fabi	06e0bea0e9	fix(export): a refused download mint no longer strands the running transfer ... `/export/ticket` mints before charging the daily limit, deliberately: charging first meant a store-capacity 503 — a server-side condition the guest cannot see or cause — still cost one of their three daily downloads, with no refund path. But a mint refused with 429 left its ticket in the store. Download tickets live six hours (they must, so a 1.4 GB transfer can resume with `Range`), and the per-session cap is four tickets OF THE SAME KIND. So: the transfer starts on ticket A -> the bar looks stuck on venue wifi -> the guest taps "Herunterladen" again -> mints 2 and 3 succeed, 4 and 5 return 429 but still mint -> the fifth evicts the oldest download ticket for the session, which is A -> the transfer drops, resumes, and 401s -> re-minting is impossible, they are at the daily limit The keepsake is unreachable until the next day, for tapping a button that appeared to do nothing. This is the failure `sse_churn_cannot_evict_a_running_ download` was written to prevent, reintroduced through the one channel that test does not cover: download tickets evicting each other. Discarding the ticket on the refusal path keeps both properties that put the mint first — a capacity 503 still costs no download, and a refused download now costs no slot. Also corrects three doc comments in this path still describing download tickets as "single-use, 30s TTL", false since they were made resumable. Stale comments here have already sent one review down the wrong path. The new spec asserts the two 429s explicitly, so it cannot pass vacuously if the daily limit stops being enforced. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 19:45:08 +02:00
fabi	e6aeaa0a8b	docs(compose): the app CPU cap cannot separate compression from the request path ... The comment read "CPU ceiling for the two image workers + ffmpeg poster extraction", which describes a separation Docker cannot make: `compression.rs` runs that work in `tokio::task::spawn_blocking` — same process, same cgroup as every Axum handler — and `cpus`/`cpu_shares` are per-container. What actually happens is worth knowing when sizing this box: `cpu.max` is `120000 100000`, so two CPU-pegged blocking workers exhaust the 120 ms quota after ~60 ms of each 100 ms period and the kernel freezes the WHOLE cgroup — uploads, feed and SSE included — for the rest of it. Over a 100-photo burst that is ~210 s during which every request can eat up to 40 ms of throttle. The value stays at 1.2: an app that can take both cores starves Postgres, and every request path goes through Postgres. A slightly stalled request beats a starved database. The comment now says which knob actually shortens the backlog (COMPRESSION_WORKER_CONCURRENCY) rather than implying this one does.	2026-08-12 23:11:57 +02:00
fabi	ac04e27e34	fix(upload): a retry after release returns the stored photo instead of refusing it ... The idempotency key was only readable as a multipart FIELD, and a field cannot be read until the body is being parsed — which happens after the lock/release pre-flight. So the replay was unreachable in exactly the case it exists for: the photo commits → the response is lost on the way back (the flaky-wifi failure the key was added for) → the host releases the gallery at the end of the night → the phone's retry answers `gallery_released`. The guest is told a photo that is sitting in the gallery was never sent. And the remedy the client offers is destructive: `open_event` clears `export_released_at` AND bumps `export_epoch`, retiring the whole keepsake generation and forcing a multi-GB rebuild on a 2-vCPU box at midnight — to re-send a photo that was never missing. Several guests on one flaky evening make this likely to happen at least once. The key is now also sent as `X-Client-Upload-Id`, which arrives with the request line, so the answer is knowable before anything is decided about locks. The multipart field stays for the concurrent case and as a fallback. Placed ahead of the hourly rate limiter too, which was the same mistake one layer up: a 40-photo burst with two retries apiece exhausted the guest's hour on uploads that had all committed the first time. The body is still drained rather than abandoned — replying before reading it makes the proxy see a broken pipe and turn a clean 200 into a 502. The spec carries its own control: a DIFFERENT photo is asserted to still be refused with `gallery_released` after the release, so the replay cannot be green merely because the gate was open.	2026-08-12 23:11:57 +02:00
fabi	137b892480	docs(runbook): the .env template no longer implies edits that compose overrides ... The template said `EXPORT_PATH=/exports # NOT pinned by compose`, which has been false for as long as the pin has existed — and it sits three lines under MEDIA_PATH, which is correctly described as pinned, so the contrast reads as deliberate. An operator moving exports to a separate volume (the remedy §13 now recommends for a full disk) would edit `.env`, see nothing change, and have no reason to suspect the compose file. All four pinned vars are now listed together with what the pin means: change it there, not here. DATABASE_MAX_CONNECTIONS carries the extra note that its value is boot-fatal when unparseable, which is why it is pinned at all.	2026-08-12 22:23:33 +02:00
fabi	b5a1580368	test(e2e): restore the download-side 404 coverage the mint pre-check displaced ... Both tests in export.spec.ts are still named "ZIP download 404s…" but now assert only that `/export/ticket` refuses. That move was right — the mint pre-validates, and refusing there spends none of the guest's three daily downloads — but it left `resolve_export_file` unasserted on the download path itself, so deleting that check would not have turned anything red. It cannot be covered by minting against an already-dead archive, because the mint refuses first. The order has to be: real release → mint while healthy → retire the generation → download. Which is also precisely what happens to a ticket already in flight when the host takes a photo down mid-download. Carries its own positive control: the ticket is asserted to serve a 200 before the epoch moves, so the 404 afterwards cannot be green for the wrong reason — an expired or never-valid ticket would 404 too.	2026-08-12 22:23:33 +02:00
fabi	6475199670	fix(feed): stop raising the stale pill on a list view that is not filtered ... The merge gate tested the raw chip state (`selectedHashtag || activeFilters .length`), but `filterParams()` — which decides what the server actually returns — ignores `activeFilters` entirely in list view. `switchView('list')` deliberately keeps a chip on `activeFilters` (an uploader chip, or a second tag) while setting `selectedHashtag` to the first TAG filter, which is null when the only chip was an uploader. So a guest who filtered the grid by an uploader and then switched to list view had a genuinely unfiltered view whose every delta raised "Neue Beiträge" instead of merging the rows in — the same pill-for-rows-that-should-have-merged this block was written to stop, one branch further in. Nothing was lost (the pill always clears) but it trains guests to ignore the one control that means something. Now gated on the effective filter, which is exact by construction: it asks the same function the fetch does.	2026-08-12 21:40:29 +02:00
fabi	55b57fc037	fix(me): two hosts deleting at once can no longer leave the event with no operator ... The last-operator guard ran on the pool, before the transaction opened. Two hosts deleting themselves at the same moment each saw the other, both passed, and the event was left with nobody who can moderate, nobody who can release the gallery, and no way to appoint anyone — because appointing requires a host. Not recoverable from inside the app. The fix is a transaction-scoped ADVISORY lock, and the two obvious alternatives are both worse: * `FOR UPDATE` on the other operators' rows DEADLOCKS. Each deleter locks the other's row and then tries to delete its own, so Postgres resolves it by killing one. The invariant survives; the loser gets a 500 instead of the sentence explaining what to do. My first attempt did exactly this, and the test caught it. * Locking the `event` row serialises cleanly but inverts the lock order every moderation path takes (upload/user rows first, event last). That is an ABBA against a path that runs constantly during the event, traded for one that runs approximately never. An advisory lock is a separate lock space, so it cannot interact with the row-lock graph at all, and it is released when the transaction ends. The loser waits, counts zero once the winner's row is gone, and is refused with the sentence it should have got. The test is a genuine concurrency test — it spawns the second deleter and asserts it unblocks to see no remaining operator. It fails against the pre-check-outside-the-transaction version and against the FOR UPDATE version.	2026-08-12 21:40:29 +02:00
fabi	19b59d6fee	docs(upload): stop claiming a proxy bandwidth control that does not exist ... `get_original`'s comment said bandwidth abuse "belongs at the proxy, where per-connection limits still work", which reads as though the removed per-IP limiter had been replaced by something. It was not: the Caddyfile sets timeouts and no rate or concurrency directive, and the tower stack is TraceLayer alone. Removing the limiter was right — the venue is one NAT address, so that bucket throttled the whole party's feed — but the route is now unbounded, and the comment should say so rather than imply cover. Records the actual cost (no-store plus the derivative fallback plus the nonce'd retry, against a 15-slot pool that upload commits compete for) and the shape a real fix would take: a concurrency semaphore over media streaming, not a request-rate bucket.	2026-08-12 20:51:51 +02:00
fabi	010bcc0e3c	fix(build): stop a stale or missing keepsake viewer from shipping silently ... Three ways the compiled-in viewer could be wrong, none of which anything would have reported. Found by mutation-testing the guard added below — it failed when it should have passed, and the reason was the second bullet. * `include_dir!` registers NO rebuild dependency. Run `npm run build` in frontend/export-viewer, then `cargo build`, and cargo sees no source change and reuses the cached binary — carrying the PREVIOUS index.html. The file on disk and the file in the binary disagree, git is clean, every check passes, and Memories.zip ships a stale viewer. Confirmed empirically: after replacing the artifact the compiled-in copy did not change until a source file was touched. A build.rs now declares `rerun-if-changed` for `static/export-viewer` AND `migrations` — sqlx::migrate!() embeds its directory the same way, and there the stale snapshot is worse still: the binary boots against a database that already ran a newer migration and crash-loops with VersionMissing. * `emptyOutDir: true` deleted the committed artifact BEFORE generating. That was safe while the build could not fail; it no longer is, because `inlineThemeFonts` now calls `this.error` on a keepsake that is not self-contained. A failed build left the directory empty — and include_dir! over an empty directory compiles fine, while `write_viewer_with_data` iterates zero files and returns Ok. The result is a valid archive with every photo and no viewer. The output is one overwritten file, so nothing accumulates without the wipe. * Nothing asserted the viewer was there at all. Now asserted at the point of use (bail rather than write a viewer-less keepsake) and in a test that checks presence, plausible size, and that no `url(/...)` survived inlining — the three ways it can be present but useless. The Dockerfile copies build.rs with the sources rather than with Cargo.toml, so the dependency-cache layer stays byte-identical and the dummy build does not run it.	2026-08-12 20:51:51 +02:00
fabi	8af8c4fab7	docs(runbook): validate the Caddyfile before the freeze, and pair down-migrations with a rollback ... Nothing anywhere executes the production `Caddyfile` before the real deploy — the e2e stack mounts `e2e/Caddyfile.test` — and a syntax error there is total: Caddy exits, `restart: unless-stopped` loops, 443 is dead for the whole event, and `docker compose up -d --force-recreate caddy` still exits 0 while it crash-loops. Step zero now validates it. I ran it against the current file (which I changed last commit, unexercised): "Valid configuration", and the new `read_body 30m` adapts to `read_timeout: 1800000000000`ns as intended. And a warning §9 needed: a down migration is not a standalone repair. Roll the IMAGE back first. `Upload::create` sends an `ON CONFLICT ... WHERE` predicate that must match the live partial index exactly and is not compile-checked, so running 026's or 031's down against the current binary turns every upload carrying a client_upload_id — i.e. every upload from the shipped client — into a runtime 500. 026's down can also fail outright on any database where a guest deleted and re-uploaded a photo; it rolls back cleanly, but you cannot go below it. Both verified against a live Postgres.	2026-08-12 20:00:52 +02:00
fabi	301e6636a5	fix(audit): give the audit trail the names that make it readable ... Migration 029 made `actor_id`/`target_id` non-FK on the stated grounds that "the record must survive the actor's account being removed, which is exactly when it is most likely to be wanted". All eleven call sites then passed None for both name columns — so what survived a deletion was a bare uuid resolving to nothing: the guarantee, minus the only thing that made it useful. `record` now resolves whatever the caller omitted, in one query, so no call site can forget. `me::delete_account` passes its names explicitly because it has already hard-deleted the row by then — that is the one record a host is most likely to be reading the next morning ("whose photos disappeared?"). Also: `actor_role` is written with `as_str()` rather than `format!("{actor_role:?}")`. The Debug spelling is not a stable wire format, so a derive change or a renamed variant would have silently started writing a different string into a column nothing validates. Migration 029's header lists three action slugs (`promote_user`, `demote_user`, `delete_user`) that no call site has ever emitted, and it cannot be corrected — editing an applied migration changes its checksum and crash-loops every database that ran it. The real list, verified against the call sites, is documented in this module instead, along with the fact that there is no read endpoint and the query to use by hand. A NULL name fails silently, so it is now asserted: names resolved from ids, names surviving the row's deletion, and a row still written when neither can be resolved (an audit write must never fail the action it records).	2026-08-12 20:00:52 +02:00
fabi	4916eed436	fix(deploy): ship the swap ceilings, pin the last boot-fatal env var, and correct docs that misdirect ... * memswap_limit is now IN docker-compose.yml on all four services. Compose sets Memory but leaves MemorySwap unset, and Docker then permits swap equal to the memory limit — so following §5's "add 2 GB of swap" silently DOUBLED every ceiling, to ~5 GiB on a 3.82 GiB box. Nothing OOMs; instead Postgres's working set becomes swap-eligible on a shared-tenancy SSD, turning a bounded OOM-kill that restarts in seconds into unbounded latency with no signal but "everything is slow". The runbook told the operator to hand-add it, which also broke §0's own gate that docker-compose.yml must be unmodified. Verified rather than assumed: service-level memswap_limit does compose with deploy.resources.limits.memory (docker inspect → Memory=1073741824 MemorySwap=1207959552). * DATABASE_MAX_CONNECTIONS pinned in compose. It is the one env var that is now boot-FATAL when unparseable — the right call, but it means a stray quote or a trailing inline comment in .env crash-loops the app behind a live Caddy. MEDIA_PATH, EXPORT_PATH and APP_PORT are pinned for weaker reasons. * .env.example's quota narrative was sized for a CX33: "~30 GB of a fresh 70 GB" on a box with 40 GB. And on THIS box the fixed point never binds at all — ~210 MB/guest is below the 500 MiB floor, so everyone gets the floor and the per-user quota stops bounding aggregate growth. What actually stops uploads is the keepsake preflight at ~8 GB of media. That paragraph is what an operator reads when a guest is blocked, and it pointed at the wrong knob. * The emergency card gains the one disk symptom that can appear mid-event, where `df -h` — its only disk instruction — actively misleads: the gate fires ~10 GB + 2.2x media BEFORE the disk is full, so df shows ~20 GB free at the moment uploads are being refused. * Two code comments that now assert the opposite of the code: claim_job promised that "the update_progress liveness check bails such a worker out early" — it cannot, its predicate is on the job row, which a reopen does not touch, so a mid-export reopen grinds the whole gallery to completion on a 2-vCPU box during the live event. And prune_superseded_archives still argued "deleted bytes cannot be rolled back" as an invariant, after the reclaim path was changed to prune even when that will not close the shortfall. Both now describe what the code does. * Smaller corrections: runbook §3's "two 48 MP photos ≈ 800 MB" scenario is unreachable (compression.rs takes an exclusive heavy permit, so they serialise) and contradicted .env.example; "all four healthy" is wrong since caddy has no healthcheck; a README line reference pointed at a comment added by the same commit that broke it.	2026-08-12 19:10:45 +02:00
fabi	182e712a0e	fix(export): a resumed download can no longer splice two archives together ... `serve_file` emitted no validator — no ETag, no Last-Modified — and ignored If-Range entirely, while `resolve_export_file` re-reads `export_current` on EVERY request and a download ticket survives 20 redemptions over 6 hours. So: a guest's 500 MB Gallery.zip drops at 500 MB. The host takes a photo down — epoch bumps, the rebuild lands, the old generation is pruned. The client resumes with `Range: bytes=500000000-`. The ticket and session are both still valid, the handler resolves the NEW archive, seeks 500 MB into a different file of a different length, and streams. The client concatenates the halves into a structurally corrupt ZIP. Nothing logs an error anywhere; a 404 would have been the correct answer. Now every response carries an ETag over the generation-stamped filename plus the length, and a partial is served only against a matching If-Range. A Range with no validator — curl -C -, wget -c, the Android download manager, all of which resume blindly — gets the whole file instead. Restarting a download is a cost; a corrupt keepsake is not recoverable. Browsers send If-Range, so this is also the first release where their resume works at all: with no validator to send, they simply refused to try.	2026-08-12 19:10:45 +02:00
fabi	f403222200	fix(deploy): a permanent upload outage, a dead-on-arrival Caddy, and 11pm commands that don't run ... * Caddy had no read_body, on the reasoning that "a slow body still has to actually send bytes". That is an argument about disk, and disk is not the scarce resource: upload_admission budgets concurrent bodies at 4096 MiB and reserves the DECLARED cap, so a video/* upload reserves 500 MiB. Eight connections that stall mid-body hold the whole budget, every other guest waits 20s and gets a 503, and it never recovers on its own — the permit is held until the handler returns. No attacker needed: eight guests starting real videos and walking out of AP range does it, and TCP will not reap those sockets for hours. 30m carries a 500 MB upload at ~2.2 Mbit/s, so it does not fail the uploads this product exists to collect. * APP_PORT is presented in .env.example as an ordinary editable line, while the healthcheck hardcodes 127.0.0.1:3000 and the Caddyfile hardcodes app:3000. Change it and the app boots and serves happily on the new port, the healthcheck fails forever, app never turns healthy — and because caddy is gated on service_healthy, CADDY NEVER STARTS. Port 443 dead for the whole event, sole diagnostic "dependency failed to start". Pinned in compose beside MEDIA_PATH and EXPORT_PATH, which are there for this reason. * Runbook §12's recovery commands do not run as written: unwrapped "$POSTGRES_USER" is expanded by the operator's shell, which does not have it, so psql answers `FATAL: role "" does not exist`. §9 documents that trap two hundred lines earlier and wraps its own calls in sh -c; §12 did not. This is the block you run with the app crash-looping behind a live Caddy. Its DELETE also hard-coded versions 21,22,23 as if to be copied verbatim, on a tree that now has 31 migrations — now explicitly an example, with the instruction to take the numbers from the actual boot error. * Migration counts corrected across the runbook and .env.example (22 -> 31, commit count 154 -> 196). All four were presented as literal command output the operator is invited to reproduce.	2026-08-12 09:15:55 +02:00
fabi	4b61f4552b	test(e2e): fix a flake that went red when the app behaved correctly ... storage-purge failed roughly one run in three on two unrelated races, both of which blamed whatever change happened to be in flight. `page.goto('/admin')` rejected with "interrupted by another navigation" or ERR_ABORTED when the admin layout redirected to /admin/login first — i.e. the test went red precisely when the app did the right thing, quickly. The assertion is the waitForURL that follows, which does not care how the navigation ended, so the goto is now allowed to reject. (waitUntil: 'commit' narrows the window but an abort can beat commit too.) And the PIN test read the page's execution context while the layout's boot hydration was still in flight, which surfaced as an intermittent "Execution context was destroyed". Settles the page first. Verified with 50 consecutive runs, previously ~1 in 3 red.	2026-08-12 09:15:40 +02:00
fabi	5aa2b2e886	fix(frontend): stop a parked photo being stranded for the session, and fix an SSE id ... A parked upload has three ways to be released, and two were weaker than the toast that promises "wird gesendet, sobald die Sperre aufgehoben ist": * The live user-shown / event-opened events only reach a tab with an open stream, and streams are opened by /feed, /diashow, /export, /host and /admin — NOT /upload, which is exactly where the toast sends the guest to watch their queue. * The boot-time release ran once and swallowed any failure, so a single failed request on venue wifi — the condition the whole parking mechanism exists for — skipped it for the entire session, leaving the row reading "Du bist gesperrt." after the ban was long lifted. Now retried once. Deliberately NOT on a 401: api.get already answered that by clearing auth and redirecting to /join, so a second attempt can only fire a second redirect two seconds later, by which time the guest may have navigated away. (That is not hypothetical — it made an existing browser-chaos spec fail while I was writing this.) Guarded rather than an early return, so the SSE listener registrations below still run. Also: noteDelivered mapped upload-processed to p.id, but that payload carries upload_id, so it recorded nothing — the docstring claimed a property the code did not have. And it recorded user-shown against a `carried` clause that only ever means "hidden", where it could only suppress a later genuine signal.	2026-08-12 09:15:40 +02:00
fabi	9f239882ac	fix(export-viewer): make the self-contained guard, and its spec, actually load-bearing ... The font-inlining guard only caught a RENAME. It asked "did /fonts/<listed family>.woff2 disappear?", so an ADDITION walked straight past it — and an addition is the likelier accident: someone doing ordinary app work adds a display font or a decorative background to the shared theme, has no reason to open a viewer build config, and ships a keepsake that reaches for /fonts/Playfair.woff2 on the guest's own disk. font-display: swap hides it, so the artifact looks right to everyone who happens to have the file locally and renders in Times New Roman for the couple. It now asserts the invariant instead of a list: nothing in the emitted keepsake may reference an external URL. Self-maintaining, and it covers fonts, images and stylesheets alike. In writeBundle rather than generateBundle — generateBundle runs more than once and the stylesheet is not inlined on the earlier pass, so asserting there fails a perfectly good build. viewer-no-broken-tiles gets a positive anchor. Its "nothing is broken" check filters img elements, so a viewer that rendered NOTHING yields [] and passes: the one spec whose whole subject is that the images resolve was the one that would have stayed green through a total viewer regression. Everything else it checks comes from the backend and the classic head script, neither of which needs the viewer bundle to have run. And a CI job, because neither of the above fires on its own: no workflow, Dockerfile or script built this viewer, so the guard could sit disarmed indefinitely, and the committed artifact — compiled into the binary with include_dir! — could drift from its source with nothing to say so.	2026-08-12 09:15:24 +02:00
fabi	a2b3cb0e8d	fix(db): run migrations on their own connection, not a pooled one ... after_connect puts lock_timeout = 5s on every pooled connection, and the migrator inherited it. Migrations that take ACCESS EXCLUSIVE — 026's index swap, 027's ADD COLUMN — then turn a short WAIT into a hard FAILURE. The runbook installs an hourly pg_dump (§10.2) and tells the operator to back up before deploying; pg_dump holds ACCESS SHARE on `upload` and `"user"` for its whole run, and the runbook is full of psql snippets that do the same. Boot into that window and the migration aborts, create_pool errors, main exits 1, and `restart: unless-stopped` crash-loops the app behind a live Caddy. The rollback is clean and a later retry succeeds, which is precisely what makes it a baffling intermittent outage rather than an obvious one. 026's own comment reasons that "this runs at boot before the server accepts requests, so the brief lock costs nothing" — true of the app's own sessions, and it does not cover anything else on the database. statement_timeout is dropped for the migrator too: a migration on a real table can legitimately outlast the 15s a request is allowed.	2026-08-12 09:15:24 +02:00
fabi	a428fe6957	fix(social): make the counts clients patch with ban-aware, like the view ... Migration 028 added `NOT is_banned` to v_feed.like_count and v_feed.comment_count, but not to the two scalar counts in social.rs — which are returned in the response AND broadcast over SSE, and which clients use to patch a card in place rather than refetching. So the two disagreed the moment anyone was banned: the host bans a guest, the feed correctly drops to the lower number, and the very next like on that photo pushes the unfiltered count back to every open client — including the host's, who is watching that number to confirm the ban took. It stayed wrong until a full page-1 refetch. Both call sites carried comments asserting they mirror the view. 028 made those comments false without touching them; this makes them true again.	2026-08-12 09:15:07 +02:00
fabi	6afb33e5b6	fix(export): four ways the keepsake could be lost, stranded, or published empty ... * The HTML completeness guard counted manifest ROWS, and there are up to two per upload — a thumbnail and a full variant. Thumbnails are 400px JPEGs the export generates itself into its own temp dir, so they are no evidence that any original was captured. After the guard was relaxed to bail only on "nothing written at all", that case could no longer fire while thumbnails kept succeeding: if the media volume became unreadable after the stat pass, every original open failed, every thumb open succeeded, and a keepsake with 100 thumbnails and ZERO full-resolution photos published green, done at the live epoch, with the download button lit. Boot recovery skips a done job, so nothing would ever have rebuilt it. Now counts photos, not files. * A decoder panic failed the ENTIRE keepsake. The `?` was on the JoinError, not on the closure's Result, so a panic in the image crate propagated out where the same file merely failing costs one tile — and it was deterministic, because "Neu erzeugen" reads the same poison file and dies the same way. That is the exact failure shape the completeness guard was relaxed to eliminate, arriving through the other door. * delete_account armed both export jobs and then spawned the workers AFTER an awaited file-removal loop. Axum drops a handler future on client disconnect, and every other invalidate_and_arm call site spawns with no intervening await. Dropped inside that loop, the keepsake is left with the epoch bumped, both rows pending at that epoch, and no worker: the downloads 404 and the UI sits on "Wird vorbereitet..." until someone reboots the app. Deleting your account from a phone that walks out of range is enough. * The daily download quota was charged before the ticket could fail, so a store-capacity 503 — a server-side condition the guest cannot see or cause — still cost one of their three downloads. There is no refund path.	2026-08-12 09:15:07 +02:00
fabi	9b38d31f97	fix(upload): stop a late retry from undoing a host takedown ... Migration 026 freed the idempotency key as soon as deleted_at was set, so a retry after a delete uploads afresh instead of 409ing forever. That rationale only considered the GUEST deleting. deleted_at is also set by host_delete_upload, and there the same rule reverses a moderation decision: 1. Guest uploads; the row commits and the photo appears, but the response is lost on the way back — the flaky-wifi case the key exists for — so the phone keeps the queue item. 2. The host takes the photo down. Epoch bumped, keepsake rebuilt without it. 3. The phone reconnects ten minutes later and retries. The key is free, the INSERT succeeds, and the photo is back — in the feed and in the next keepsake, under a NEW uuid that matches nothing in the host's moderation history, with nothing logged to say a takedown was reversed. Migration 031 keeps the key claimed for a host takedown and releases it only for a guest's own delete, so the retry resolves to the duplicate path and is refused. The refusal now says why ("von den Gastgebern entfernt") rather than "already processed", which invites another try. The index predicate and the ON CONFLICT arbiter are changed in lockstep; these queries are not compile-checked, so a drift between them is a 500 on exactly the retries the index exists to serve. Verified against a real Postgres: live retry suppressed, host takedown holds the key, guest delete releases it. The integration test's copy of the insert is updated too — it is verbatim by design, and a stale copy would have kept passing.	2026-08-12 09:14:51 +02:00
fabi	1b3ca46f8a	fix(auth): three ways one guest on the venue NAT could lock everyone else out ... All three are the same mistake in different clothes: a limit keyed on an IP that, behind the venue's NAT, is the entire party plus the host. * join_ip_rate_per_min was raised 60 -> 300 last round and it never took effect. A config default is only a fallback for a MISSING key, and migration 017 seeds this one, so the seed won and the raise was dead code on every real install. Migration 030 raises the seeded value the way 015 already did for upload_rate_per_hour. The e2e guard could not see this: it fires 12 concurrent joins, which is green at 60 and at 300 alike. * /recover's per-(IP, name) bucket charged EVERY request, including successful ones, and refused before verifying the PIN. Its ceiling clamps to 4. So four POSTs naming "Braut Sophie" with PIN 0000, from any phone on the venue wifi, locked Sophie out of her own recovery for fifteen minutes WITH THE CORRECT PIN — and four more every fifteen minutes sustained it indefinitely, at a rate far under every volume ceiling above it. The benign version needs no attacker: the host mistypes their own PIN four times. Hosts are promoted guests whose only credential is that PIN, and /recover is their only way back after losing a session. Now it counts failures, and a spent budget changes what a FAILURE answers instead of refusing outright. Guessing is bounded exactly as before — wrong PINs are what spend it — with the per-account lockout underneath. * /admin/login's pre-verify ceiling had the same shape, and the escape hatch was circular: admin_login_rate_enabled is only flippable through PATCH /admin/config, which needs the session being refused. One phone posting twice a minute cost the operator moderation, gallery release and every config key, including the ones that would undo it. Exceeding the ceiling now shortens the hash-permit wait rather than refusing: the CPU bound was always the semaphore, never this bucket, so a flood still sheds itself while a correct password gets a truthful answer. Adds a regression test that reads the value a fresh database actually ends up with, by replaying the migrations — the drift that made the first bullet invisible is not otherwise detectable from the code.	2026-08-12 09:14:39 +02:00
fabi	0c0d5d5981	fix(deploy): give Postgres a CPU floor that Docker actually honours ... `deploy.resources.reservations.cpus` was doing nothing. Outside Swarm, `docker compose up` silently drops it — verified by inspecting a running container, where CpuShares, CpuQuota and CpusetCpus were all unset while `limits.cpus` and `reservations.memory` came through as NanoCpus and MemoryReservation. So the comment calling it "the piece that actually protects the database" described a guarantee the box never had. It matters on the CX22 the runbook targets: the ceilings sum to 1.2 + 0.6 + 0.5 = 2.3 on 2 vCPU, so the other services can oversubscribe the machine, and with every container on the default weight Postgres competed on equal footing with two image resizes and an ffmpeg poster. Replaced with `cpu_shares`, which does survive the translation — db 2048, caddy 1024, app 512, frontend 256 — so the weighting only binds when the CPU is actually saturated, which is the moment the database must not lose. The Caddyfile gains a 10s header-read timeout: there was no read timeout anywhere, so a client could hold a connection, a tokio task and a `.tmp` file open indefinitely by sending one byte a minute, and the upload sweeper is keyed on mtime precisely so a live upload never ages out. Body reads stay unbounded — a 500 MB video over cellular legitimately takes minutes, and a body timeout would fail exactly the uploads this product exists to collect. .env.example documents that estimated_guest_count is a live input to the quota divisor rather than the inert setting both it and the runbook previously implied. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 22:44:48 +02:00
fabi	32dfe6874a	test(e2e): make nine red specs assert the contracts the code actually implements ... The e2e suite had never been run during this audit. It failed 9 of 256; seven of those predated the audit's changes, established by building a stack from a clean HEAD worktree and running the same specs against it rather than guessing. Most were stale assertions rather than product defects: - quota.spec solved for a target limit using the observed uploader count, but the divisor is max(active, estimated_guest_count, 1) and that config seeds at 100 — so every limit it aimed for came out 100x small and every "within quota" upload 413'd. - rate-limit-shared-nat destructured `ticket` from a 429 body and fetched with `ticket=undefined`, turning the 429 under test into an unrelated 401. It also faked a release with no archive on disk, so the mint's pre-check 404'd and the per-day limiter was never reached; it now does a real release and asserts 200 rather than "not 429". - ddos allowed only [200,429] from ten concurrent streams, so it failed on the very defence it exercises: four tickets per session survive and the rest correctly 401. Now asserts exactly four, which a tightened cap or an inverted eviction order would catch. - auth-tampering asserted a throttled IP is refused EVEN with the correct password. That contract was deliberately removed — it let any phone on the venue NAT lock the operator out of their own admin panel, with a circular escape hatch. Inverted, plus a new check that a success does not refill an attacker's bucket. - moderation-ui assumed a ban leaves a comment "stuck on screen"; `list_for_upload` filters banned authors, so it is hidden from everyone including the host. Now pins the pair that matters — the ban hides it, and the host's permanent removal survives an unban — and the UI leg it used to own is restored as a separate test on a reachable comment. The export specs mint with `?kind=` now that a download ticket is bound to one archive, and four of them assert the mint's 404 rather than the download's: with the kind always known, the pre-check refuses up front instead of after charging a daily download for an archive that cannot be served. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 22:44:48 +02:00
fabi	a53729a704	fix(frontend): park uploads that cannot succeed, and stop two false signals ... The upload queue gains `parkedFor`, so a photo rejected for a reason that cannot change on its own stops re-pushing itself. A ban used to come back as a generic `forbidden`, which purged the blob and moved the row to `blocked` — a terminal state with no retry button — so lifting a ban restored everything except the photo actually in flight. Ban and release are now distinct codes that keep the blob, charge no attempt, and tell the guest what has to happen. `releaseResolvedParks` drains them at boot from /me/context, because the live `user-shown` / `event-opened` events only reach a tab that was open when the host acted, and the usual sequence is the other way round. Two signals were firing on nothing. A filtered feed set `feedStale` on EVERY delta without deduping — and the delta cursor boundary is inclusive while sse.ts deliberately rewinds `lastEventTime`, so deltas routinely re-return rows already delivered. With the backstop polling every 60-120s, a guest who tapped a hashtag got a "Neue Beiträge" pill they could never clear, each tap costing a full filtered refetch. It now dedupes in both branches. The SSE liveness backstop had the mirror problem: `noteDelivered` harvested id, upload_id AND user_id from every payload, so by the time anything was deleted or anyone banned, their ids were already marked delivered from ordinary traffic about live content. The `deleted_ids` and `hidden_user_ids` clauses were false essentially always, leaving a half-open socket undetected while a host moderated into a feed nobody was listening to. Each event now records only the id its own clause tests. Also: /admin no longer bounces to /join on a cleared session — AUTH_ROUTES had the `/admin` prefix, which suppressed clearAuth() on the dashboard and let the login guard bounce back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 22:44:26 +02:00
fabi	f5c55d6f92	chore(backend): route wiring, error mapping, and a crossbeam-epoch bump ... Cargo.lock moves crossbeam-epoch to 0.9.20, clearing RUSTSEC-2026-0204. Targeted rather than a broad `cargo update` across 406 crates, which is not a change to make days before a live event. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 22:44:26 +02:00
fabi	8720571beb	fix(export-viewer): inline the webfonts so the offline keepsake is self-contained ... The viewer inherits `src: url('/fonts/Inter.woff2')` from the shared theme CSS. That is correct for the app, which serves `static/fonts/` from the site root — but the keepsake is opened from file:// off a USB stick or a Downloads folder, where `/fonts/...` resolves to the root of the guest's DISK. Both requests 404, and `font-display: swap` makes it silent: the viewer renders in a fallback system font with nothing server-side able to report it. Found by opening a real released keepsake in a browser and watching `requestfailed` — no other signal exists, which is the recurring lesson about this artifact. Fixing it in the shared CSS would inline ~154 KB into every app page load for nothing, and shipping a `fonts/` folder beside index.html gives the guest a directory they can break by moving one file. So the substitution belongs in the build that knows its output has no origin. The plugin errors the build if the theme ever stops referencing those URLs, rather than silently shipping another keepsake in Times New Roman. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 22:44:10 +02:00
fabi	c9a4d4a9c0	fix(export): stop the keepsake guards from destroying the keepsake ... Two guards added to protect the archive each had a failure mode worse than the one they prevented, and both were unrecoverable — which is what makes them worth reverting rather than tuning. The completeness gate refused to publish once skips passed max(2, 10% of expected). That refusal is DETERMINISTIC ACROSS RETRIES: the unreadable files are still unreadable when the host taps "Neu erzeugen", and the gallery is already released so the uploads cannot be collected again. On a 30-photo event, four bad files meant nobody ever got the other 26. That is precisely the "one-photo gap becomes total loss" outcome MAX_SKIPPED_FRACTION's own comment says it exists to avoid. Anything short of an empty archive now publishes and logs the counts at error level. `written == 0` stays fatal — a wrong MEDIA_PATH is a misconfiguration the host CAN fix and retry, and it once shipped a few-hundred-byte ZIP containing zero photos that passed every automated check. The space reclaim refused to prune unless it freed the entire shortfall, to protect an archive that no handler can serve: a download resolves through `export_current`, which requires `job.epoch = event.export_epoch`, and the epoch only increments. Meanwhile `reclaimable` is scoped to the caller's own prefix — one old archive — while `deficit` is sized for both halves plus the reserve. So on a tight disk each worker measured its own share as insufficient and neither pruned, though the two shares were jointly sufficient. Every "Neu erzeugen" reran the identical arithmetic and refused identically: permanently stuck, with dead archives nothing would reclaim and nothing could serve. It now prunes what it can and lets the re-check decide, so the sibling's prune lets the host's retry converge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 22:44:10 +02:00
fabi	7154b3a810	fix(upload): remove the /original rate limit that would have broken the feed ... The limiter added here was justified as bounding "100 guests occasionally tapping Original anzeigen". That is not what this route is. `pickMediaUrl` resolves to `preview_url ?? thumbnail_url ?? /original`, and a freshly committed upload has BOTH derivatives null until the compression worker reaches it — at COMPRESSION_WORKER_CONCURRENCY=2 that is minutes during a post-ceremony burst. So /original is the feed's hot path for exactly the newest photos, in a newest-first grid, at the busiest moment. With every guest behind one NAT the 600/min bucket is venue-wide: six new photos fanned out by `upload-new` to ~100 open feeds exhausts it, and then every original fetch from anyone 429s for the rest of the window. The tiles' own 4-second retry uses a fresh `?r=` nonce, so the clients hold the bucket saturated themselves — the whole venue watching the newest photos render as broken tiles while the projector skips slides. A per-IP bucket cannot separate one scraper from the entire party when they share an address, and these media routes are unauthenticated by design (an `<img>` cannot send a bearer token), so there is no per-user key to move to. Bandwidth abuse belongs at the proxy. Also here: the release/lock check order. `release ⇒ lock`, so testing the lock first made the `GalleryReleased` arm unreachable dead code and every post-release upload answered `uploads_locked`. The codes are not interchangeable to the client — `uploads_locked` charges a retry attempt and re-pushes the whole photo on the backoff ladder against an answer that cannot change, while `gallery_released` parks it and says the photo is safe but the hosts must reopen. Both sites now test release first, so the fast path and the commit-time re-check agree. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 22:43:50 +02:00
fabi	ec7c7f18ca	fix(auth): stop one guest on the venue NAT from locking everyone else out ... Every guest at the venue shares one public IP, so an IP-keyed limiter throttles the whole party as a single client. Three separate limits got that wrong, and the host — whose only credential is a 4-digit PIN — was the one who could not absorb it. /recover carried a cross-name failure budget checked BEFORE the account lookup, so it refused a CORRECT PIN. Thirty POSTs with invented names spent the shared budget for fifteen minutes and ~2 requests/minute sustained it indefinitely, denying PIN recovery to everyone including a host locked out of their own event. The budget is now carried as a flag: a correct PIN authenticates regardless, while wrong ones answer 429 instead of 401. Guessing stays bounded where it always really was — the per-(IP,name) ceiling and the per-account 3-strike lockout, neither of which an attacker on any IP can evade. join_ip went from 60/min to 300. A 100-guest wedding does not trickle in; it arrives when the QR code goes up, all from one address, and guests 61-100 were turned away on the one screen with no auto-retry. This limit only bounds raw volume — the per-name bucket is the anti-spam control and BCRYPT_PERMITS is the CPU bound — so it can sit well above the peak. Download tickets are now bound to ONE archive via `TicketKind::Download(ExportKind)`. Both download routes share an authenticator, so a bare ticket opened either; combined with the resume budget that made a single mint worth 40 transfers of a multi-GB keepsake while the per-day limiter, charged only at mint, never moved. `kind` is consequently required at /export/ticket; every shipped client already sends it. The per-session ticket cap is now per-kind. A 6-hour download ticket is always the oldest entry for its session, so ordinary SSE churn evicted it first — and /export opens its own SSE connection on the session that just minted it. A couple of wifi flaps mid-transfer killed the ticket, 401'd the resume, and cost the guest another of three daily downloads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 22:43:29 +02:00
fabi	963f6449a1	feat(db): idempotency keys, ban-aware counts, and a host audit trail ... Four migrations, all additive against a database that already has 001-025 applied. 026 narrows the client-upload idempotency index with `AND deleted_at IS NULL`. The old index made a soft-deleted row keep its key forever, so a guest who deleted a photo and re-sent the same one had the retry silently swallowed. The new indexed set is a strict subset of the old, so it cannot fail on existing rows. 027 adds `client_join_id`, which lets a join retry after a lost response resume the same account instead of 409ing on a name the caller itself owns. Every existing row gets NULL and the partial index excludes NULLs, so it indexes nothing at creation. 028 brings the feed view's like/comment counts in line with what the feed actually renders: a banned guest's rows were still counted, so a card showed "3 comments" above two. `comment.rs` gets the matching `NOT u.is_banned` on the live read path — the export and hashtag queries already filtered it, so the two views of one moderation action disagreed. 029 records host moderation actions, which were previously invisible after the fact. Verified by applying 001-029 to a real Postgres against seeded data, including a soft-deleted row holding a key and a banned user's like and comment. 026's down-migration legitimately fails where a deleted and a live row share a key — that is inherent to the direction, documented in the file, and sqlx never runs downs at boot. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 22:43:11 +02:00
MechaCat02	ef6d3a077a	fix: close what nine adversarial reviews found, most of it mine ... Nine focused reviews (export state machine, upload path, auth/abuse, client queue, guest UI, database, deploy/ops, regression hunt, test honesty). Every finding below was re-verified against the code before being acted on; several plausible-sounding ones were checked and rejected. ## Data loss and denial of service **One request could OOM-kill the app container.** `client_upload_id` was read with `Field::text()` — axum builds its multipart reader with no SizeLimit, so the only bound was the route's 576 MiB body limit, then decoded into a second full String. `caption` and `hashtags` go through `read_text_field_bounded` for exactly this reason; this field arrived later and missed it. Any guest, one request, and every SSE stream drops and every in-flight temp file is stranded. **Nothing bounded concurrent upload bodies.** The headroom gate can only refuse to COMMIT — the body is already streamed to a temp file by the time it runs, and neither axum, the tower stack nor Caddy limits how many stream at once. ~100 guests tapping "upload all" after the ceremony puts 10-20 GB of .tmp on a 40 GB volume, invisible to the gate, eating the reserve that keeps Postgres able to write WAL. New `UploadAdmission` budgets bytes (not requests, so one video and two hundred photos coexist) via a permit that releases on drop, so every exit path returns it. **The export decode bypassed the memory permit the compression path takes.** Same class of work — decode + resize every image in the gallery — in a bare spawn_blocking. A release fired while the last photos were still compressing put both in the same 1 GiB cgroup; the OOM kill marks the export failed and `recover_exports` re-spawns it into the same conditions on the next boot. The permit is now process-wide in `imaging`, because the constraint it expresses is the container's memory, not one worker's. **`MediaTotalCache` cached its own failure as 0.** For the whole TTL the gate then saw an empty event and collapsed to the flat reserve — the behaviour the two-halves design replaced — with no log line. And the trigger correlates with the danger: with max_connections 10 the query fails exactly during a burst. Now falls back to the last good reading and says so. **V8's heap ceiling sat above the frontend container's entire budget** (measured: 259 MB inside a 256M limit), so GC could never intervene and the only backpressure was SIGKILL under an arrival burst. ## Guest-visible **The feed stopped being newest-first after the first reconcile.** It fetches whole 100-item server pages while `uploads` grows in 20s, so everything in the gap was absent from `present`, classified as new, and prepended — ~80 photos from earlier in the evening above the newest ones. It also stalled infinite scroll, since the cursor still pointed at item 20 and the observer only re-fires on a change. The union is now sorted on the server's own (created_at, id) key, which additionally places an SSE arrival correctly. **A stale `loadMoreError` outlived every refresh and filter change**, leaving a false error above a button that returns immediately on `!nextCursor`. **A failed derivative toasted "Ein Upload konnte nicht verarbeitet werden."** for a photo sitting right there on screen — the handler still assumed 1d9fb11's pre-fix behaviour (row deleted, quota refunded, card evicted), none of which is true any more. It was the last surviving route for the "your photo is gone" signal that fix set out to remove. ## Enforcement that existed only in comments `recover_name_rate_per_15min` is clamped at the point of use: the ordering `3 x ceiling <= PIN_LOCK_THRESHOLD` is the whole control against one source locking any guest whose name is on the feed, it was asserted in a comment, and `patch_config` accepted 1..100_000. The test pinned the default constant rather than the enforced bound; it now pins the bound. ## Tests that could not fail - The gate test asserted only its own premise (`500MB x 100 > 35GB`) and never touched the gate. It now checks both controls against the same state and requires them to disagree in the right direction. - `the_banner_always_fires_before_the_upload_gate_closes` reduced to `G < G + G/4` — true for any margin, including zero, so it could not detect the banner moving to exactly the gate. It now pins the gap. - `disk_is_low`'s `free < LOW_DISK_FLOOR_BYTES` clause was unreachable (warn_at is always >= 12.5 GB against a 10 GB floor). Two tests were named after it and neither could fail if it were deleted. Clause and constant removed. - The suspension test I added last commit hard-coded the credit cap instead of importing it, so changing STALL_TIMEOUT_MS would leave it passing against a system that no longer exists. Now imports MAX_SUSPEND_CREDIT_MS. ## Stale comments corrected The prune doc still argued at length for the pre-build ordering that 1d9fb11 reversed — a reader trusting it would reopen the blocker 0506369 fixed. DISK_RESERVE_BYTES claimed to equal the banner threshold that 0506369 deliberately offset by 25%. And host.rs kept its own duplicate 10 GB literal instead of importing the constant. 154/154 backend, 59/59 vitest, clippy clean, svelte-check 0 errors, eslint clean, both builds, compose + caddy validate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 14:51:58 +02:00
MechaCat02	214f9e3062	fix: close four confirmed defects an adversarial review found ... Findings from a multi-angle review, most of them in code I wrote in the last few commits. Each was verified against the code before being acted on. ## Backend **The export daily limit was bypassable ~60x/minute.** `SseTicketStore` is untyped, and the export download quietly started reusing it. `POST /stream/ticket` is free and rate-limited at 60/min per user; `POST /export/ticket` charges one of three PER-DAY downloads. So a guest could mint at the cheap endpoint and redeem at the expensive one, each redemption streaming the whole multi-GB keepsake, `no-store`, off the same filesystem Postgres writes WAL to. Tickets now carry a `TicketKind` and `consume` requires it to match, asserted in both directions. The comment claiming "one mint is at most one download" was simply false. **`export_ticket` answered 200 `{"ticket": null}` when the store was full** — after charging a daily slot. `issue` returns `Option`; `sse.rs` handles the None with a 503 and this call site unwrapped it into the JSON body. The page toasted success, the iframe navigated to `?ticket=null`, and one of three downloads was gone. That is the phantom-success failure the pre-validation in 5b70531 exists to prevent, arriving through the other door. **`finalize_job` collapsed a DB error into "we lost the epoch race."** At that point the archive is built, fsynced and renamed, so the caller deleted the finished multi-GB file and returned the Superseded sentinel — which `abandon_if_superseded` swallows into Ok, so `mark_failed` never ran either. The row stayed `running` at 99% at the LIVE epoch: "Wird erstellt (99 %)", download disabled, forever. No sweep re-examines `running` rows and `recover_exports` runs only at boot. `claim_job`'s own doc comment says errors are distinguished there precisely because of this failure shape. A pool timeout is not exotic: max_connections 10, acquire_timeout 5s, firing at the end of a full-gallery export while 100 guests upload. **`PATCH {"hashtags": []}` was a free keepsake-retire loop.** The no-op guard only compared captions, and my comment defended the gap by claiming an identical hashtag list "is not a free loop". It is exactly one. Each request bumped the epoch, retiring the HTML keepsake; REGEN_DEBOUNCE throttles when a rebuild may start, not the bump, so at 30/min no rebuild ever gets a quiet window and /export/html 404s all event. Now compares against the stored tags. Also: four config keys migration 025 inserts (and the handlers read) were missing from `patch_config`'s allowlist, so `GET /admin/config` listed them while `PATCH` answered "Unbekannter Konfigurationsschlüssel" — the rate limits an operator reaches for while abuse is happening. ## Client upload queue **The ✕ was cosmetic.** A cancel deliberately charges no attempt and sets no backoff — so `requeueRetriable` matched it on both counts and restarted the upload from byte zero within ~120s (an `online` event, or the SSE backstop's `feed-delta` poll). It then restarted forever, because a path that never charges an attempt can never exhaust the budget that would stop it. The row read "Abgebrochen. Tippe auf „Erneut“." throughout. Cancels are now explicitly terminal until the guest taps Erneut. **The retry budget was a lifetime quota, not a rate.** Five attempts on a 5/10/20/40s ladder is ~75 seconds, so any outage longer than that — a venue AP brownout, a captive portal re-arming, an `app` restart, all with `navigator.onLine` still true — permanently parked every in-flight photo behind a per-row button three taps deep. It now refills after 10 quiet minutes, which still forbids a hot loop re-sending a 200 MB video over a shared uplink. **A test asserted a property the code does not have.** The suspension test omitted the MAX_SUSPEND_CREDIT_MS clamp the production tick applies, so it could not fail. Replaced with a helper that replays the real tick loop, and the true bound is now asserted: a 60s lock survives, a 3-minute lock aborts. 152/152 backend, 59/59 vitest, clippy clean, svelte-check 0 errors, eslint clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 14:39:54 +02:00
MechaCat02	253878e027	fix(export): give the keepsake viewer the two-phase preflight it was meant to get ... The two-phase preflight from eb0e405 landed in ONE place and was spliced inside the other. `run_zip_export` ended up containing both blocks nested, so the Gallery path pruned "Memories" archives that were not its to reclaim, while `run_html_export` silently kept the single-phase form. That left the exact deadlock the two-phase preflight exists to break, still open on half the product. At a gallery size where a rebuild needs the previous generation's bytes: the ZIP prunes its own superseded archive and rebuilds, and the HTML preflight fails against a Memories archive still on disk. The prune that would free it runs only after a success that can never happen, and any epoch bump — a guest deleting one photo — retires the current viewer immediately. Permanently stuck, unreachable from any handler, discovered at the end of the night with nobody there. Both halves now call one `ensure_export_space_reclaiming`, keyed on the caller's OWN prefix, so they cannot drift again. Three smaller things found in the same pass: - The boot-failure panel hardcoded light-mode colours, and its heading set none at all — the UA default black on the `#100f0f` dark background. On the one screen whose entire job is to be readable, and in the failure mode where the app's own stylesheet may be what did not load. Moved to classes in the inline <style> so the `html.dark` variants apply. - `.env.example` assigned RUST_LOG twice, 120 lines apart. Compose takes the last one, so an operator raising the level mid-event to chase a problem would have changed nothing, silently. - The comment justifying `detail = ?message` in error.rs still claimed `validate_display_name` allows newlines. It rejects control characters now — but that is one input against every 4xx message in the app, so the escaping is what makes the guarantee general. Said so. 151/151 backend, 58/58 vitest, clippy clean, svelte-check 0 errors, both builds, caddy validate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-08 22:48:22 +02:00