Files
buzz/crates
Matt Toohey b082b1464c test(relay): give every media e2e upload its own blob hash (#9272)
## Summary
Split out of the `flakey-monday` flake-fix series. Two Relay E2E media
tests shared one deterministic blob hash across every test in their
binaries. In enforce mode (`BUZZ_MEDIA_READ_MODE=enforce`, on for the
Relay E2E lane since #9077), a rejected publish of that shared hash left
a sticky publication marker that made ranged GETs from the other tests
return 404. Every media e2e upload now has its own blob hash.

Commits (cherry-picked from `flakey-monday`, original messages kept):
- `test(media): give each video e2e test its own MP4 blob`
- `test(media): publish images of their own in the media e2e tests`

### Root cause and fix per test

**`test_video_range_request_206` / `test_video_range_request_416`**
(`crates/buzz-test-client/tests/e2e_media_video.rs`): a ranged GET
returned 404 instead of 206/416 in 9 of 55 Relay E2E jobs.
- Root cause (confirmed): `build_test_mp4()` was deterministic, so every
test in the binary uploaded the same sha256, and the tests run in
parallel against one relay. In enforce mode, `validate_media_references`
records a sticky `media_publications` marker for every hash an event
publishes, before dispatch, so a later rejection does not undo it.
`test_video_poster_imeta_rejects_video_as_poster` published the shared
hash and was then rejected by imeta validation. From then on
`media_access` gave an uploader with no readable reference `Restricted`,
served as 404, until the accepted poster test stored its event in an
open channel.
- Fix: `build_test_mp4()` appends a top-level `free` box holding a
random UUID, so each call yields a distinct, still valid fast-start MP4.
The upload validator allows `free` and does not inspect its payload. The
relay is unchanged: the pre-dispatch marker is the documented
fail-closed contract in `docs/operator-private-media.md`.

**`test_video_poster_imeta_accepted_via_ws`** and
**`e2e_media_extended::test_ws_valid_imeta`**: hardening, not a fix for
an observed failure. Both published a fixed 1x1 JPEG byte-identical to
`tiny_jpeg()` in `e2e_media.rs`, which `test_upload_and_get` reads back
through an uploader preview. That currently passes (a readable live
reference wins before the marker matters), but a publishing test that
shares a fixed blob with other media tests is one rejected or private
event away from the same flake. Both now publish an 8x8 PNG of random
pixels from a new `unique_png()` helper; `test_ws_valid_imeta`'s imeta
declares `image/png` and the real size; `tiny_jpeg()` is removed from
`e2e_media_video.rs`.

### Related issue
N/A (flake fixes; none found).

### Testing
Human testing is still required. This PR does not carry
`buzz-review-completed`; the author has not yet run these tests
themselves on this branch.

#### Verification
These changes were verified locally on the `flakey-monday` branch before
the split, against an enforce-mode relay with docker Postgres/MinIO:
- Old code, fresh enforce-mode relay: reject test then range tests
failed both range tests with 404 at the CI lines (reproduction).
- Whole `e2e_media_video` binary, `--test-threads=8`: 20/20 passed.
- Reject test then range tests against the polluted hash: 3/3 passed.
- The CI "Media read-auth e2e" command (`e2e_media`,
`e2e_media_extended`, `e2e_media_video`, `--ignored`), 5 back-to-back
runs on the same scratch database (the persistent-relay case): 5/5 runs,
40/40 tests each time.
- `cargo fmt --check` and `clippy --tests`: clean.

Nothing was re-run on this split branch: the workstation was overloaded,
so no tests, builds or linters were executed after cherry-picking. CI on
this PR is the verification for the split branch.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: mtoohey <mtoohey@squareup.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-09 13:56:58 -05:00
..