2 Commits

Author	SHA1	Message	Date
MechaCat02	0a33189e7e	test(loadtest): audit which real files the upload validator actually refuses ... "Will my photos be accepted?" was being answered by reasoning about the size caps, which is the wrong method — size is only one of the paths that refuses a file. The magic-byte allowlist, the decode budget (12000 px axis / 256 MiB alloc, both code constants no setting can relax), the disk gate and the per-user quota all reject too, and only the running server knows how they interact. `acceptance-audit.mjs` pushes every file in the pool through the real endpoint and groups the refusals by the server's own German message. Against the 945-file wedding set with the raised limits it answered the question exactly: 935 accepted, and the only 10 refusals are the HEIC files. Deliberately not a load test — no personas, no viewers, no think-time. It measures admission, so it does not wait for the compression backlog to drain. The sim stack gains two overridable vars, so the harness can be pointed at the configuration actually deployed rather than the defaults: SIM_APP_IMAGE / SIM_FE_IMAGE (audit a release image, not a local build) and KEEPSAKE_ENABLED, which changes the disk gate and therefore changes what gets refused. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 22:42:28 +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>	2026-08-20 22:58:17 +02:00