fabi/EventSnap
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: close the nine ways an unattended event loses photos or dies

Browse Source 
Every one of these was found in the pre-event audit, verified against source, and
survives to production on the current main. Grouped by what actually goes wrong.

PHOTOS DISAPPEAR

* compression.rs no longer soft-deletes on a failed derivative. The guest got a
  201, watched the card appear, then watched it vanish — the row left v_feed,
  find_visible_media and BOTH keepsakes, while its bytes sat on disk for 14 days
  waiting for a cleanup nothing announced. No screen anywhere lists compression
  failures, so recovery meant hand-written SQL that also had to re-add the
  refunded quota. Now it does exactly what the ENOSPC arm beside it already did
  and documented as correct: keep the row, serve the original, retry on the next
  boot (bounded by derivative_attempts). `upload-deleted` is no longer emitted;
  `upload-processed` is, so the card re-renders instead of sitting on a
  placeholder.

* A 413 is now a reversible lock, so the blob survives. The quota moves — free
  disk falls, uploader count rises — so a guest goes over it having done nothing,
  and treating that as permanent meant a 400 MB video was pushed across cellular
  in full and THEN deleted from IndexedDB. Gone on both sides, and unrecoverable
  for an in-app camera capture that exists nowhere else.

* quota_limit_bytes gained a floor and a stable divisor. The ceiling used to
  decrease monotonically all evening; it now settles at max(uploaders,
  estimated_guest_count) — a config key that was seeded, validated in the admin
  whitelist, and read by no code at all. The floor is clamped to what the disk
  can actually back, so a full volume still yields zero rather than handing out
  an allowance it cannot honour.

* Because that floor gives up the aggregate guarantee the formula used to imply,
  uploads now check a hard 10 GB reserve first, independent of every quota
  toggle. postgres_data, media_data and exports_data share one filesystem: the
  end state was not a degraded feature, it was Postgres unable to write WAL.

THE ARCHIVE DISAPPEARS

* prune_superseded_archives runs only after the new generation lands. It ran
  before the preflight, reasoning the old archive was already unreachable — true
  of reachability, false of recoverability. An epoch is a value that can be
  rolled back; deleted bytes cannot. Any failed rebuild left the event with NO
  keepsake at all.

* The export preflight reserves the same 10 GB. `free < needed` authorised an
  export sized at exactly free, which ran for half an hour and landed the box at
  zero with the keepsake still unfinished.

THE APP DIES

* The feed reconcile re-reads the id set after its awaits instead of reusing one
  captured up to three round-trips earlier. The new-upload SSE handler prepends
  during exactly that window, so the row was both already present and absent from
  the stale set — prepended twice, and a duplicate key in a keyed {#each} throws
  in production, not just dev. The SSE handler and loadMore now dedupe too.

* Added routes/+error.svelte. Without it any uncaught error fell through to
  SvelteKit's unstyled English 500 with no reload control — inside a chromeless
  standalone PWA with no URL bar, for the rest of the evening.

THE OPERATOR IS LOCKED OUT

* admin_login verifies the password BEFORE charging the rate bucket, and a
  correct password is never throttled. The old order made this a denial of
  service against its own operator: every guest shares one NAT IP, the check ran
  first, so five requests a minute from any phone in the room kept the bucket
  full — and the escape hatch needed the admin session being blocked. A generous
  separate ceiling still bounds bcrypt CPU.

THE PROJECTOR DIES

* The preload budget is now strictly inside the dwell. At the 3s option the 4s
  budget could never land a commit on a slow uplink, so the wall froze on one
  photo while the queue drained silently behind it.

* The wake lock retries every 30s while visible, and the page says so on screen
  when the browser has no wake lock API. visibilitychange was the only retry
  trigger and a kiosk never changes visibility, so one refusal — iOS in Low Power
  Mode, say — was permanent.

* Caddy: /api/v1/upload/*/display joins the cacheable carve-out. The backend set
  max-age=300 on it and the blanket no-store silently replaced it, so a projector
  re-fetched a full-size JPEG per slide, ~2-4 GB over an evening on the uplink
  the guests are uploading over.

Also removes Upload::soft_delete, now unreferenced and an unscoped footgun next
to soft_delete_in_event.

Verified: 146/146 backend tests against a live Postgres, clippy clean, 51/51
vitest, svelte-check 0 errors, eslint clean, vite build, caddy validate, compose
YAML parse.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
MechaCat02
2026-08-08 21:32:52 +02:00
parent 61119be817
commit 1d9fb11c7b
12 changed files with 448 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
frontend/src/lib/diashow/wakelock.ts
View File

@@ -16,6 +16,19 @@ type WakeLock = { request: (t: string) => Promise<SentinelLike> };
let sentinel: SentinelLike | null = null;
let visibilityHandler: (() => void) | null = null;
let retryTimer: ReturnType<typeof setInterval> | null = null;
/**
* How often to retry while visible and lock-less.
*
* `visibilitychange` was the ONLY retry trigger, and a kiosk never changes visibility: the
* projector tab is opened once and left alone for eight hours. So a single refusal at startup
* was permanent. Refusal is not exotic either — iOS declines Screen Wake Lock outright in Low
* Power Mode, which is exactly the state a tablet that has been sitting on a table all
* afternoon is in. The symptom is the screen sleeping mid-party and someone having to walk
* over and tap it, repeatedly.
*/
const RETRY_INTERVAL_MS = 30_000;
async function request(wakeLock: WakeLock): Promise<void> {
try {
@@ -33,9 +46,17 @@ async function request(wakeLock: WakeLock): Promise<void> {
}
}
export async function acquireWakeLock(): Promise<void> {
/**
* Acquire the screen wake lock, and keep trying.
*
* Returns whether the API exists at all, so the caller can tell "the browser cannot do this,
* warn the operator" (Firefox, Safari < 16.4, most TV browsers) apart from "asked for, may
* still arrive". It deliberately does NOT report whether the first request succeeded — that
* answer goes stale immediately, and the retry loop below is what actually matters.
*/
export async function acquireWakeLock(): Promise<boolean> {
const wakeLock = (navigator as Navigator & { wakeLock?: WakeLock }).wakeLock;
if (!wakeLock) return;
if (!wakeLock) return false;
await request(wakeLock);
// Re-acquire when the page becomes visible again (the OS releases the lock
@@ -48,6 +69,17 @@ export async function acquireWakeLock(): Promise<void> {
};
document.addEventListener('visibilitychange', visibilityHandler);
}
// The kiosk case: visible, no lock, and no visibility change ever coming. Cheap enough to
// run all evening — it does nothing at all once a lock is held.
if (!retryTimer) {
retryTimer = setInterval(() => {
if (document.visibilityState === 'visible' && sentinel === null) {
void request(wakeLock);
}
}, RETRY_INTERVAL_MS);
}
return true;
}
export async function releaseWakeLock(): Promise<void> {
@@ -63,4 +95,8 @@ export async function releaseWakeLock(): Promise<void> {
document.removeEventListener('visibilitychange', visibilityHandler);
visibilityHandler = null;
}
if (retryTimer) {
clearInterval(retryTimer);
retryTimer = null;
}
}

18
frontend/src/lib/event-config-store.ts
View File

@@ -21,8 +21,22 @@ export type EventConfig = {
};
export const eventConfig = writable<EventConfig | null>(null);
/** Convenience flag for the comment UI. Optimistic `true` until /event resolves. */
export const commentsEnabled = writable<boolean>(true);
/**
* Convenience flag for the comment UI. `null` until `/event` answers — deliberately NOT an
* optimistic `true`.
*
* Optimistic-open was wrong in the direction that costs a guest their words. Production pins
* `COMMENTS_ENABLED=false`, so on every cold open the comment button, the grid tile button and
* the whole lightbox composer rendered for as long as `/event` took — up to the 20s api timeout
* on congested venue wifi, and PERMANENTLY if that request failed, because the catch below
* leaves the last value in place. A guest would type a comment, tap Senden, get a red error,
* and watch the text be discarded.
*
* `null` is falsy, so every `{#if $commentsEnabled}` hides and every `$commentsEnabled ? a : b`
* picks the comments-off copy until the server has actually said otherwise. The failure mode
* flips from "offered something that doesn't work" to "revealed a moment late".
*/
export const commentsEnabled = writable<boolean | null>(null);
type PublicEventDto = {
name: string;

28
frontend/src/lib/upload-queue.ts
View File

@@ -535,13 +535,24 @@ export function classifyUploadStatus(status: number): UploadOutcome {
*
* Reversible when:
* - the backend tagged it `uploads_locked` (event closed / gallery released — a host can reopen), OR
* - it's `quota_exceeded` (413). The per-user ceiling is `free_disk * tolerance / uploaders`,
* which MOVES: the numerator falls and the denominator rises all evening, so a guest who was
* comfortably under it at 20:00 is over it at 22:00 through nobody's action, and a host
* deleting content or the hourly reclaim can put them back under it just as passively. It is
* the textbook reversible lock, and treating it as permanent meant a 400 MB video was pushed
* across cellular in full and THEN deleted from IndexedDB — gone on both sides, unrecoverable
* without re-picking from the camera roll (impossible for an in-app camera capture). OR
* - it's ANY 403 we can't positively identify as a permanent ban (`forbidden`). An unparseable
* 403 body (proxy/WAF/captive portal) must NOT purge the blob — losing a photo is the worst
* outcome, and 403 is the reversible-lock status here.
* A `forbidden` 403 (banned) and every non-403 4xx (e.g. 413 quota) are permanent → purge.
* A `forbidden` 403 (banned) and every other 4xx (too large, wrong type) are permanent → purge.
*/
export function isReversibleLock(status: number, errorCode: unknown): boolean {
return errorCode === 'uploads_locked' || (status === 403 && errorCode !== 'forbidden');
return (
errorCode === 'uploads_locked' ||
errorCode === 'quota_exceeded' ||
(status === 403 && errorCode !== 'forbidden')
);
}
/**
@@ -982,7 +993,9 @@ async function uploadItem(id: string): Promise<void> {
settle(() => reject(new LockedError(body?.message || 'Event ist geschlossen.')));
break;
}
// Any other 4xx the server will keep rejecting (banned / quota).
// Any other 4xx the server will keep rejecting (banned, too large, wrong
// type). Quota is NOT here any more — it moves with free disk and the
// uploader count, so it is a reversible lock handled above.
let msg = body?.message || 'Upload nicht möglich.';
if (!body?.message && xhr.status === 413) msg = 'Speicher-Limit erreicht.';
settle(() => reject(new TerminalError(msg)));
@@ -1028,9 +1041,12 @@ async function uploadItem(id: string): Promise<void> {
throw e; // Propagate to processQueue for scheduling
}
if (e instanceof LockedError) {
// Event closed / gallery released, but a host can reopen — KEEP the blob and park
// the item as retryable so it survives until reopen. The `event-opened` SSE
// (bindSse) auto-resumes it; a manual "Erneut" also works. Never purge here.
// A condition that can lift without the guest doing anything: the event is closed or
// the gallery released (a host can reopen), or the storage quota is currently
// exceeded (it moves with free disk and the uploader count, and a host takedown or
// the hourly media reclaim puts them back under it). KEEP the blob and park the item
// as retryable so it survives until then. `event-opened` and the `feed-delta`
// reconnect both auto-resume it; a manual "Erneut" also works. Never purge here.
const exhausted = chargeAttempt(entry);
entry.status = 'error';
entry.error = withRetryHint(e.message, exhausted);

40
frontend/src/routes/+error.svelte Normal file
View File

@@ -0,0 +1,40 @@
<script lang="ts">
// Without this file SvelteKit renders its built-in fallback: an unstyled English
// "500 / Internal Error" with no reload control. That is reachable from any uncaught
// render or load error, and `ssr = false` means there is nothing else on the page to
// fall back to. In a `display: standalone` PWA there is also no URL bar, so a guest who
// hit it had no way back to the app at all for the rest of the evening.
//
// Deliberately dependency-free: no stores, no api client, no fetch. Whatever broke may
// be one of those, and an error page that can itself throw is worse than none.
import { page } from '$app/state';
function reload() {
location.reload();
}
</script>
<div class="flex min-h-dvh flex-col items-center justify-center gap-6 px-6 text-center">
<div class="flex flex-col gap-2">
<p class="font-mono text-xs tracking-widest text-gray-500 uppercase">
Fehler {page.status}
</p>
<h1 class="text-2xl font-semibold text-gray-900 dark:text-gray-50">
{page.status === 404 ? 'Diese Seite gibt es nicht' : 'Da ist etwas schiefgelaufen'}
</h1>
<p class="mx-auto max-w-sm text-gray-600 dark:text-gray-400">
{page.status === 404
? 'Der Link stimmt nicht ganz. Geh zurück zur Galerie, dort sind alle Fotos.'
: 'Die Seite konnte nicht geladen werden. Meistens hilft es, sie neu zu laden.'}
</p>
</div>
<div class="flex flex-col gap-3 sm:flex-row">
{#if page.status !== 404}
<button type="button" class="btn btn-primary" onclick={reload}> Neu laden </button>
{/if}
<!-- A full document load, not `goto`: if the client-side router is what broke, a
client-side navigation would fail exactly the same way. -->
<a href="/feed" data-sveltekit-reload class="btn btn-secondary"> Zur Galerie </a>
</div>
</div>

43
frontend/src/routes/diashow/+page.svelte
View File

@@ -13,6 +13,20 @@
const DWELL_OPTIONS = [3000, 6000, 10000];
// Cap on how long we wait for the next image to decode before showing it anyway.
const PRELOAD_TIMEOUT_MS = 4000;
// How far inside the dwell the preload budget must finish.
//
// `advance()` starts the preload and `scheduleNext()` starts the dwell timer together, and
// `commit()` is discarded if the slide token has moved on. So whenever the preload budget
// is >= the dwell, a screen whose images consistently decode slowly (cold cache on a
// congested venue uplink — the normal state for a projector on party wifi) can never land
// a commit: at 3s dwell the 4s preload is discarded, the next one gets 4s and is discarded
// at 6s, forever. The wall sticks on one photo for the rest of the night while the queue
// drains silently behind it, and nothing on screen says anything is wrong.
//
// Bounding the budget strictly below the dwell means the timeout always fires first and
// commits whatever it has — a possibly-undecoded image is a far better outcome than a
// frozen wall that needs a human.
const PRELOAD_HEADROOM_MS = 500;
// If every source for a slide is unreadable we skip it — but bail out of skipping after
// this many in a row so a total media outage can't hot-loop the show.
const MAX_CONSECUTIVE_SKIPS = 5;
@@ -41,6 +55,10 @@
// Consecutive slides skipped because no source decoded — reset the moment one shows.
let consecutiveSkips = 0;
let dwellMs = $state(6000);
// Set when the browser has no Screen Wake Lock API at all (Firefox, Safari < 16.4, most TV
// browsers). The operator sets this screen up once and walks away, so a silent no-op meant
// discovering the OS had dimmed the projector only by looking at it.
let wakeLockUnsupported = $state(false);
let transitionId = $state('crossfade');
let paused = $state(false);
let showOverlay = $state(false);
@@ -177,7 +195,12 @@
clearTimeout(timer);
action();
};
timer = setTimeout(() => done(() => commit(candidates[i])), PRELOAD_TIMEOUT_MS);
// Always strictly less than the dwell — see PRELOAD_HEADROOM_MS.
const preloadBudget = Math.max(
250,
Math.min(PRELOAD_TIMEOUT_MS, dwellMs - PRELOAD_HEADROOM_MS)
);
timer = setTimeout(() => done(() => commit(candidates[i])), preloadBudget);
const pre = new Image();
pre.src = candidates[i];
pre.decode().then(
@@ -414,7 +437,9 @@
return;
}
showBottomNav.set(false);
void acquireWakeLock();
void acquireWakeLock().then((supported) => {
wakeLockUnsupported = !supported;
});
document.addEventListener('fullscreenchange', handleFullscreenChange);
showControls(); // show briefly on entry, then fade after the idle timeout
unsubs.push(onSseEvent('upload-processed', handleUploadProcessed));
@@ -481,6 +506,20 @@
<div class="text-white/60">Lade…</div>
{/if}
<!-- The one thing the operator must know before walking away. This browser cannot hold a
screen wake lock at all, so the OS will dim or lock the display on its own schedule and
somebody will have to walk over and tap it. Placed bottom-left, out of the controls'
corner, and deliberately not auto-hidden with them — it is setup information, and it is
only ever shown when it is actionable. -->
{#if wakeLockUnsupported}
<div
class="pointer-events-none absolute bottom-4 left-4 max-w-xs rounded-md bg-black/60 px-3 py-2 text-left text-xs text-white/70 backdrop-blur"
>
Dieser Browser kann den Bildschirm nicht wachhalten. Bitte die automatische
Bildschirmsperre am Gerät deaktivieren.
</div>
{/if}
<!-- Controls appear on pointer/keyboard activity and fade when idle. Still fully
keyboard-reachable (any key reveals them), so the show is never a trap. Notch-safe. -->
<div

30
frontend/src/routes/feed/+page.svelte
View File

@@ -319,6 +319,11 @@
feedStale = true;
return;
}
// Never prepend an id we already hold. The server broadcasts once, but a
// reconcile that resolves just after this handler runs re-delivers the same
// row, and a duplicate id in a keyed `{#each}` is a thrown error, not a
// cosmetic glitch.
if (uploads.some((u) => u.id === upload.id)) return;
uploads = [upload, ...uploads];
} catch {
/* ignore */
@@ -540,9 +545,24 @@
const bridged = known.size === 0 || fetched.some((u) => known.has(u.id));
if (page + 1 >= windowPages && bridged) break;
}
// RE-READ the ids here rather than reusing `known` from before the awaits.
//
// `known` was captured up to three round-trips ago — 1-6s on venue wifi. The
// `new-upload` SSE handler prepends to `uploads` unconditionally during exactly that
// window (list view is designed to stay live), so an upload that arrived mid-fetch is
// BOTH already in `uploads` and absent from the stale `known`. It then passed the
// filter below and was prepended a second time, putting the same id at two positions
// in an array consumed by keyed `{#each}` blocks — and Svelte 5 throws
// `each_key_duplicate` in production builds, not just dev. With no `+error.svelte` the
// guest got the unstyled fallback page, inside a chromeless PWA, for the rest of the
// evening.
//
// `known` above is still the right value for the bridging check: that one genuinely
// asks "did the head we started from overlap what the server returned".
const present = new Set(uploads.map((u) => u.id));
const byId = new Map(fetched.map((u) => [u.id, u]));
uploads = uploads.map((u) => byId.get(u.id) ?? u);
const fresh = fetched.filter((u) => !known.has(u.id));
const fresh = fetched.filter((u) => !present.has(u.id));
if (fresh.length) uploads = [...fresh, ...uploads];
}
@@ -611,7 +631,13 @@
params.set('cursor', nextCursor);
params.set('limit', '20');
const res = await api.get<FeedResponse>(`/feed?${params}`);
uploads = [...uploads, ...res.uploads];
// Same hazard as the reconcile: this page was requested against the list as it
// stood before the await, and a `new-upload` prepend or a filter change since
// then can put a row we are about to append already in the array. Keyed `{#each}`
// treats that as fatal, so filter against the CURRENT ids, not the ones we started
// with.
const present = new Set(uploads.map((u) => u.id));
uploads = [...uploads, ...res.uploads.filter((u) => !present.has(u.id))];
nextCursor = res.next_cursor;
} catch (e) {
toastError(e);