MechaCat02 164c7d2aa3 test(upload): prove the stored bytes are the guest's bytes, not just that a 201 came back ...

v0.18.3 through v0.18.6 were one failure in four disguises: the browser handing
the queue something that was not the file. An empty body first (WebKit stores a
picked `File` as a reference to an OS file iOS then deletes), and once the bytes
were copied, the risk of a SHORT one — that copy is a multi-second chunked loop
for a video, and the same purge can land partway through it.

Every check that missed them shared one shortcut: asserting the upload was
ACCEPTED. A truncated file is accepted. It passes the magic-byte sniff, the size
cap and the decode budget, is stored, gets a preview, appears in the gallery —
and is still not the guest's video. Acceptance was never the question.

So this drives the real composer through the real file chooser, then fetches the
stored original back and compares its SHA-256 to the file on disk. It also names
the two copy paths, because they are different code and only one of them can
produce a short blob: at or below 4 MB a single `arrayBuffer()`, above it the
chunked loop. A run with no file over 4 MB says so rather than reporting a pass
it did not earn.

Replaces the two throwaway scripts these hotfixes were verified with. Reports
which entries the upload sheet offers, so a run also records whether
PUBLIC_CAMERA_ENABLED was in effect.

Verified against v0.18.6: 32 KB single-read and 14.8 MB chunked, both
byte-identical.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-23 16:09:21 +02:00

6.5 KiB

Raw Permalink Blame History

View Raw