10 Commits

Author	SHA1	Message	Date
fabi	2b57f1728e	fix(upload): the truncation guard never fired -- it checked the wrong field ... v0.18.3 added a 400 branch to keep a guest's photo when the request body arrives truncated, gated on `body.error !== 'bad_request'`. Its premise was that axum's multipart rejection is a plain-text 400 with no envelope, so an envelope with `bad_request` in it must be a considered verdict on the file. That is false for the path that actually fails, and the branch was inert against the exact incident it was written for. A guest on the live event lost a photo at 07:22; replaying the same truncation against the running backend at 07:50 produced a byte-identical log line: WARN request rejected status=400 code="bad_request" detail="Error parsing `multipart/form-data` request" and this response body: 400 application/json {"error":"bad_request","message":"Error parsing `multipart/form-data` request"} A `bad_request` envelope. The guard evaluates false, the item still goes terminal, and the blob is still purged. The handler never reaches axum's extractor rejection: it pulls the fields itself and wraps `MultipartError` in `AppError::BadRequest` -- bare from the field loop, prefixed with "Datei konnte nicht gelesen werden: " from the chunk loop. Both arrive indistinguishable BY CODE from "file too large". Axum's own plain-text rejection does exist (no boundary in Content-Type -> "Invalid `boundary` ...") but is a different error and not one a webview produces. So the rule keys on the MESSAGE, and moves into an exported `isIncompleteBody` beside `isReversibleLock`, matching how the other data-loss-critical rules in this file are made testable. Tests transcribe the four responses captured from the running backend, so reverting to an envelope check fails them. Matching an upstream Display string is the weakness here and is called out in the doc comment: an axum upgrade could reword it and silently re-open the data loss. The durable fix is a distinct backend code (`body_incomplete`) this can prefer once it exists -- deliberately not done now, because it means an app image release and the backend has not needed one since v0.18.0.	2026-08-22 08:13:40 +00: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
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	05063694d2	fix: close eight regressions the audit pass found, five of them mine ... Two adversarial reviews over 61119be, 1d9fb11 and eb0e405. The merge itself came back clean — client_upload_id end to end, TempFileGuard's arm/retarget/disarm, the supervised sweep wiring and v_feed's column parity were all verified sound. What follows is what my own three commits broke. BLOCKER — a post-release rebuild was permanently impossible, and it 404'd the keepsake 1d9fb11 deferred prune_superseded_archives to run only on success, so a failed rebuild could no longer destroy the last good archive. It did not follow that through: ensure_export_space runs BEFORE the prune, so at rebuild time the previous generation is still on disk and counted against free. That halves the gallery a rebuild can survive (~4.6 GB) relative to what the upload gate accepts (~7.8 GB) — and it self-locks, because invalidate_and_arm bumps the epoch on COMMIT, which 404s both download routes immediately, while the only code that could free the space now runs only after a success that can never happen. A guest deleting their own photo is enough to trigger it. Recovery needed `docker exec rm`. Now two-phase: try to build while preserving the old generation; if that genuinely does not fit, reclaim it and try once more. Strictly better than both the original ordering and my change — the old archive is sacrificed only when it is the only way to get a new one. BLOCKER — the deferred prune could delete the last archive when a worker LOST the race run_*_export_inner returned Ok(()) on the superseded/discard path, so `res.is_ok()` fired the prune with the worker's own RETIRED epoch as keep_seq. At that moment the winning generation is still `pending` with no file, so protected_files is empty and the last good archive was deleted with no replacement. Exactly the invariant deferring the prune was meant to establish. Returns Err(Superseded) now, which abandon_if_superseded already swallows for the caller. BLOCKER — the low-disk banner could never fire before the wall eb0e405's gate refuses at `free < keepsake + DISK_RESERVE`, while disk_is_low warned at `free < keepsake`. The two differ by the whole reserve, so the wall always came first: every guest blocked from uploading while the host dashboard showed ~27 GB free and no banner, with nobody on site. disk_is_low now shares the gate's expression plus a 25% margin, and a test asserts the banner fires at the gate threshold across the whole gallery-size range. BLOCKER — I raised the unauthenticated bcrypt ceiling 24x on a 2 vCPU box 1d9fb11 moved admin_login's tight bucket after verify_password (correct — that is what stops a guest locking the operator out) but replaced the incidental 5/min bound on bcrypt with 120/min and nothing global. bcrypt is on spawn_blocking, but tokio's blocking pool is 512 threads, so "off the runtime" is not "bounded": enough concurrent verifies preempt both async workers and uploads, feed and SSE stall. Three unauthenticated endpoints reach bcrypt and every guest shares one NAT IP, so per-IP limits bound nothing globally. Adds a process-wide semaphore of `cores - 1` around both verify and hash, and drops the ceiling to 30. Also correcting my own claim: "a correct password is never throttled" was wrong. The failure bucket cannot block it, but the CPU ceiling still can. The code comment said so; the commit message did not. BLOCKER — migration 025 could crash-loop the app on boot Its UPDATE derives `Name (8hex)` with no guard against idx_user_event_name_ci. A guest who had already joined as exactly that string makes the migration fail, which propagates out of create_pool, exits main, and `restart: unless-stopped` turns it into a permanent loop — a worse version of the lockout the migration exists to clean up. Now skips colliding rows (create_admin_user already falls back to Admin-<8hex>, so the cleanup is convenience, not load-bearing). Also `role = 'guest'` rather than `<> 'admin'`, which was renaming legitimately promoted hosts named "Host". DEGRADATION — the watchdog's suspension credit was unbounded Background tabs are throttled to ~1 tick/min WITHOUT the network stack pausing, and the tick gap cannot tell that from a freeze. Crediting every late tick grew the observed silence by only one interval per real minute, so a dead socket took ~18 minutes to detect while holding the queue's processing latch. Credit is now capped at one stall window and REFILLS on real progress: an upload that is moving survives any number of screen locks, while one that is silent and suspended is detected within ~3 minutes. DEGRADATION — the 4xx log line was an unauthenticated log-injection vector validate_display_name allowed newlines, several 4xx messages interpolate the name, and %message wrote it unescaped. Two unauthenticated /join requests could forge arbitrary lines in the only forensic record an unattended event has. Fixed at both ends: control characters rejected at the door, and `detail = ?message` escapes on the way out (which also stops colliding with tracing's reserved `message` field). 401/404 drop to DEBUG — they carry no operator signal and were the cheapest lines for a scanner to use to roll the 30 MB log window in minutes. DEGRADATION — the quota floor was inverted exactly where it mattered `computed.max(MIN.min(budget))`: `budget` is the whole disk's share, so below 500 MiB the "floor" became the entire remaining budget and EVERY uploader was authorised all of it — 400 MB free, 3 uploaders, 300 MB each. A test pinned that as correct under the name `the_floor_never_exceeds_what_the_disk_can_back`. Both fixed. Also replaces the headline gate test, which asserted its own precondition inside an `if` on that precondition and could not fail. It now pins what actually binds the gate to the preflight — that required_free_bytes charges for both halves — plus the ceiling band. Verified: 151/151 backend tests against a live Postgres, clippy clean, 58/58 vitest, svelte-check 0 errors, eslint clean, both builds, caddy validate, and the migration collision reproduced against Postgres 16 before and after. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-08 22:33:43 +02:00
MechaCat02	eb0e405562	fix: gate uploads on keepsake headroom, and close five unattended-event gaps ... The box is 2 vCPU / 4 GB / 40 GB, not the 4 vCPU / 8 GB / 80 GB that the audit, the committed comments and README's sizing section all assumed. That correction is what the first change is about; the rest are the remaining pre-event items. THE ARCHIVE COULD BECOME UNBUILDABLE WHILE UPLOADS KEPT SUCCEEDING `required_free_bytes` is `media × 1.1 × 2` — the ZIP and the HTML viewer are each gallery-sized — and the export preflight also wants DISK_RESERVE_BYTES on top. The upload gate, though, only refused below a FLAT 10 GB reserve. On 40 GB that let uploads run to ~25 GB of media while a release needed `2.2 × 25 + 10` = 65 GB free. Every upload in that band succeeded and the keepsake could then never be built: the product's entire promise, failing silently at the end of the night with nobody there. The gate now enforces the invariant that actually matters — never accept an upload that would make the keepsake unbuildable — sharing `required_free_bytes` with the preflight so the two cannot drift into disagreeing about the same question. Uploads stop at ~8 GB of media on this disk, with a German message naming the cause. Refusing the 1001st photo beats losing all 1000. `media_total.rs` backs it: SUM(user.total_upload_bytes) over ~100 rows, cached 5s, rather than `estimate_export_bytes`'s join across every upload. It counts hidden and banned users' bytes, which the export excludes — skew in the SAFE direction, so the gate closes marginally early rather than late. Fails open on a query error. A test pins the gate against the preflight across the whole gallery-size range, and a second asserts the per-user floor alone would over-commit the volume — i.e. that the global gate is what must bind. THE WATCHDOG ABORTED HEALTHY UPLOADS EVERY TIME A PHONE WAS POCKETED `Date.now()` advances while a backgrounded phone is frozen but `setInterval` does not, so the first tick after a screen lock read the whole sleep as silence and aborted — re-sending a video from byte zero and burning one of five PERMANENT auto-attempts. The interval is now its own suspension detector: a tick that arrives 125s late for a 5s schedule credits that window back, because a period the watchdog could not observe is not evidence of silence. Chosen over a `visibilitychange` listener, which only covers causes that fire that event — a throttled-but-visible tab, a closed lid and an occluded window all freeze timers without one — and which would have needed module state, an SSR guard and a teardown for strictly less coverage. `performance.now()` was rejected because Safari pauses it across system sleep on some paths and Chrome does not. The credit buys one fresh window, not immunity: a socket iOS reaped while backgrounded still aborts ~90s after resume rather than hanging for `xhr.timeout` (5-60 min) with the queue's `processing` latch held. Two latent leaks found while in there: `xhr.abort()` on a request already in readyState DONE emits no `abort` event, so `settle()` never ran and the interval re-aborted every 5s forever while `activeUploads` kept a stale entry (the ✕ button silently stopped working); and a synchronous throw from `xhr.send` — a blob whose backing store the OS purged — leaked the same way. Both closed. OKLCH MADE THE DELETE BUTTON INVISIBLE ON SAMSUNG'S DEFAULT BROWSER red/amber/green were never in the @theme block and fell through to Tailwind v4's `oklch()` defaults, which Safari <15.4, Chrome <111 and Samsung Internet <22 cannot parse: `var(--color-red-600)` is then invalid at computed-value time, `background-color` falls back to transparent, and `.btn-danger` renders white text on nothing. Pinned to Tailwind's own defaults gamut-mapped to sRGB by Lightning CSS — the converter already in this pipeline — so modern browsers render exactly what they render today. Verified against seven hex fallbacks it had already emitted for the /alpha forms. rose and teal (avatar chips) had the same leak. The app CSS goes from 40 oklch declarations to 0. Also fixes `--color-purple-950`, which was simply missing: `dark:bg-purple-950/50` on the host dashboard was rendering default violet on EVERY browser, off-brand. The keepsake viewer only picks this up on a rebuild, so its committed artefact is rebuilt here too — still single-file, still zero external references. A BRICKED BOOT LOOKED LIKE A SPINNER FOREVER With `ssr = false` the page is empty until the bundle mounts, so a chunk 404 after a redeploy or a dead uplink left the guest on the boot spinner with no message, no reload control, and in a standalone PWA no URL bar. A 15s timeout in the existing nonce'd IIFE (no CSP change) swaps in German copy and a reload button. Deliberately a timeout rather than feature detection: a SyntaxError in the bundle is invisible to any capability check. Plus a <noscript>, since there was nothing at all to see without JS. EVERY 4xx WAS INVISIBLE AT ANY LOG LEVEL tower_http counts 4xx as a success, so it logs at DEBUG while production runs at info. If guests spend the evening hitting 429s or 413s, the post-event logs said nothing. Now one WARN per client error; 5xx excluded because Internal already logs its source chain and the pool-exhaustion 503 logs at construction. A DEAD FRONTEND SERVED A BLANK 502 `handle_errors 5xx` with an inline German page (the caddy service mounts only the Caddyfile, so there is no volume to ship a static file through). Verified empirically against this config, not from documentation: an upstream 404 through `reverse_proxy` still arrives as untouched `application/json`, and only a dial failure renders the page. That mattered — the keepsake download navigates a hidden iframe and DEPENDS on a real 404/429 arriving, and swallowing those would have been worse than the blank 502. CONFIG CORRECTIONS FOR THE REAL HARDWARE DATABASE_MAX_CONNECTIONS 30 → 15: sized to 2 vCPU rather than to the guest count. Since migration 024 a feed page costs well under a millisecond, so connections are no longer spent waiting, and 30 backends crowd the db container's 1 GB on a 4 GB host. COMPRESSION_WORKER_CONCURRENCY stays at 2 — the merged heavy-image permit already serialises anything over 150 MiB, so the "two 48 MP photos" worst case that number was sized against is unreachable; dropping to 1 would halve light-path throughput and push more feed tiles onto full-size originals. README's sizing section rewritten for the actual disk. Verified: 149/149 backend tests against a live Postgres, clippy clean, 57/57 vitest, svelte-check 0 errors, eslint clean, vite build, export-viewer rebuild, caddy validate, compose YAML parse. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-08 22:07:56 +02:00
MechaCat02	6fd75adb27	fix(ops): bound logs, drain ffmpeg's stderr, and stop three silent hangs ... Six independent operational defects, none of which needed a new feature to fix. Log rotation. Docker's json-file driver is unbounded by default, and those files land on the HOST filesystem — outside every deploy.resources.limits in the compose file, and on the same disk as postgres_data and media_data. A full disk stops Postgres writing WAL, which takes the event down. Capped at 10m x 3 per service. Log level. RUST_LOG was set in neither .env.example nor docker-compose.yml, so the code fallback WAS the production level — and it was `debug`, with tower_http=debug emitting a line per request and per response into that unrotated file. Now info, with tower_http=warn to state that those spans are diagnostics, not an access log. ffmpeg pipe deadlock. run_ffmpeg piped stdout and stderr and then called wait(), which drains neither. Once the ~64 KiB pipe buffer filled, ffmpeg blocked writing and wait() never returned — burning the full 120s timeout, twice per seek position, three times per compression attempt. And the timeout is an Err, so the end state was a soft-deleted upload: a guest's playable video destroyed by a poster-frame failure. Now stdout is null (nothing ever read it) and stderr is drained by wait_with_output, whose tail is logged on a non-zero exit. Note wait_with_output consumes the child, so the old kill-on-timeout is gone; kill_on_drop(true) already covers it. Readiness probe. /health never touched the pool, so the disk-full endgame above stayed green all the way down. Adds /health/ready (SELECT 1 under 2s) as a SECOND route — the compose healthcheck deliberately keeps pointing at /health, because caddy gates its startup on it and a DB-dependent probe would turn a Postgres blip into the reverse proxy refusing to start. api.ts request timeout. The abort timer was cleared in a finally around fetch(), which resolves on the response HEAD — leaving res.text() uncovered and no longer abortable. An upstream that sends headers then stalls the body hung the call forever. The timer now lives until the body is read, including the 204 path (which otherwise leaked a live 20s timer per no-content request). Upload XHR watchdog. The XHR had no timeout while processQueue held the isProcessing latch across it; on a half-open socket neither error nor abort ever fires, so the latch pinned and the queue wedged. Bounds SILENCE rather than total duration — a 500 MB video over a venue uplink legitimately runs 30+ minutes while making steady progress. Rejects as NetworkError, which is already the retryable branch, so a stalled upload now recovers like any network blip. IndexedDB failures. addToQueue called getDb() unguarded and handleSubmit had no catch, so a private-mode refusal or a QuotaExceededError on a large blob left a permanent "Wird hochgeladen…" spinner, no toast, and — for an in-app camera capture — the only copy of the photo gone. Now reported as 'failed', which keeps the staged files on screen and stays on the page. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 22:25:23 +02:00
fabi	f8cba95e49	chore(frontend): add ESLint + Prettier; fix real findings; format the tree ... The frontend had no JS/TS linter — only svelte-check. Add flat-config ESLint (typescript-eslint + eslint-plugin-svelte) and Prettier (tabs/single-quote, matching the existing style). Rules encode "catch bugs, not enforce taste": - svelte/require-each-key KEPT — it is the exact bug class as the feed mis-tap fix. Fixed every flagged block: keyed activeFilters, filteredUsers, stagedFiles (by previewUrl), captionTags, admin tabs/jobs/users, the export-viewer suggestions/filters/comments, and the static skeleton loops. - svelte/prefer-svelte-reactivity KEPT — inline-disabled only the verified-safe sites (a local freq Map in a $derived.by, throwaway URLSearchParams query builders), with a reason each. - svelte/no-navigation-without-resolve OFF — wants resolve() around every goto()/href; taste, not a bug, and pure churn. - svelte/no-unused-svelte-ignore OFF — those comments are consumed by svelte-check, which ESLint can't see, so it wrongly calls them unused; removing them would reintroduce a11y warnings. - no-explicit-any OFF for *.test.ts only (partial fixtures legitimately use any). Real code fixes beyond keys: removed a dead jobLabel(), an unused ViewerComment import and unused catch binding, an unused scroll-lock arg, and replaced an empty interface with a type alias. Then `prettier --write` (54 files). Formatting only. Verified: eslint clean, svelte-check 0 errors, vitest 46 passed, vite build succeeds. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 20:45:42 +02:00
fabi	df275bbefa	fix(rereview): close export-flip race + queue-dedup reload regression ... Adversarial re-review of the persona-audit + audit-followup rounds (6411747..) found one HIGH and one MED regression plus LOW gaps. All fixed with coverage. HIGH — export stale-keepsake resurrected by an open_event race A reopen landing in the window between a *current* export worker's finalize_job and its ready-flag flip cleared export_released_at + the ready flags but left the export_job row `done` at the same release_seq. The seq-guarded flip then still matched and re-set export_{zip,html}_ready=TRUE on a pre-reopen snapshot; the next re-release read that stale TRUE and skipped regeneration (`if ready { continue }`), serving a keepsake missing every upload from the reopen window — the exact data loss migration 012 exists to prevent. Both ready-flip UPDATEs are now additionally anchored on `export_released_at IS NOT NULL`, so a landed reopen makes the flip a no-op and the re-release regenerates cleanly. MED — queue dedup broke for reloaded items loadQueue rebuilt QueueItems from IndexedDB without copying lastModified, which the new addToQueue dedup keys on. A file re-selected after a page reload / PWA relaunch missed the duplicate check and uploaded twice. Rehydration now carries lastModified (extracted to a pure, tested entryToQueueItem helper). LOW - diashow: clear the upload-processed debounce timer in onDestroy (no stray post-unmount /feed fetch). - USER_JOURNEYS §9.5: document the reconnect-delta ban replay (hidden_user_ids / uploads_hidden_at, migration 013), not just the live user-hidden SSE. - e2e api-client: drop the misleading hide_uploads param from banUser — the backend takes no body and always hides; strip the dead boolean at all call sites. Tests - Extract isReversibleLock (the terminal-403 KEEP-vs-PURGE-blob discriminator) into a pure exported helper + unit tests, so the data-loss-critical branch is covered without an XHR harness. - entryToQueueItem unit tests lock the lastModified-carry regression. - Document the export flip-race guard in the reopen/re-release spec (the sub-ms finalize↔flip interleave isn't deterministically forceable with fast fixtures; covered by the SQL guard + the end-to-end completeness test). Verified: backend 40 tests, frontend 44 unit tests, svelte-check 0 errors, e2e 156 passed / 1 skipped on chromium-desktop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 21:47:44 +02:00
fabi	36fe59caa5	fix(user-flow): persona-audit fixes — ban replay, locked-upload data loss, host UX, admin session ... Follows the perf + security + user-flow work with a role/persona audit (guest, host, admin, projector) and fixes across three review rounds. Highlights: HIGH - Ban now replays on reconnect. A ban isn't a soft-delete, and the `user-hidden` SSE has no replay, so a client that missed it (esp. the unattended diashow) kept cycling a banned user's slides. New `uploads_hidden_at` (migration 013) + `hidden_user_ids` in /feed/delta; feed + diashow evict those users. Applied even on a truncated delta. MEDIUM - Locked-upload data loss: a photo staged offline during a lock/release was purged as a terminal 4xx and lost when the host reopened. New reversible `uploads_locked` error code; the queue keeps the blob and auto-resumes on the `event-opened` SSE. - Reopen after release now warns (ConfirmSheet) that it revokes the published keepsake. - Host "forgotten-PIN" badge updates live (`pin-reset-requested` was broadcast but never in KNOWN_EVENTS / subscribed); host page also refetches on `pin-reset` so a two-host race can't hand out a conflicting PIN. - Ban modal copy fixed (read-only ban, not "session ended"); Degradieren/Sperren/Entsperren hidden on peer-host rows for non-admins (they always 403'd). - Host dashboard shows live keepsake generation progress / ready state + link to /export. - Admin JWT moved to sessionStorage (§11.1) to bound exposure on shared devices. Export generation guard (H1 from the prior round, hardened): per-(event,type) `release_seq` (migration 012) with seq-guarded claim/finalize/mark_failed/update_progress, per-generation temp/final paths, download follows `file_path`, prune only strictly-older generations. LOW: diashow coalesces upload-processed (avoids self-rate-limit); event-closed reconciles galleryReleased; /recover gains a forgot-PIN request + drops a stale cached PIN on 401; delta `>=` tie-break + 429 retry; misc copy/labels. Adds e2e: ban-replay, upload-lock-code, and rewrites export-reopen-rerelease with a data-completeness test. Reconciles USER_JOURNEYS §9/§11. Verified: cargo build clean, 40 unit tests, svelte-check 0 errors, 33 frontend unit tests, 155 e2e passing on chromium-desktop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 21:06:28 +02:00