Genace
Sign inGet started

generated media corruption tests: reject bad bytes before publishing

A video job can succeed while the bytes copied into your application’s storage are unusable. Test delivery validation independently with local files and a controllable HTTP origin. The goal is to prove that invalid artifacts stay unpublished and recovery reuses the original output instead of generating a replacement automatically.

Start with a known local asset

Choose a small video or image fixture that your test environment can legally store and decode. Record its expected media properties, size, and checksum. Derive bad variants from that fixture rather than downloading real customer assets during the test run.

from pathlib import Path

original = Path("fixtures/valid-video.mp4").read_bytes()
Path("fixtures/empty.mp4").write_bytes(b"")
Path("fixtures/truncated.mp4").write_bytes(original[:len(original) // 3])
Path("fixtures/html-as-video.mp4").write_text(
    "<html><body>upstream unavailable</body></html>", encoding="utf-8"
)

This script derives local test files only. Run it in a test directory and keep the valid source fixture under your repository’s asset policy. A truncated file is not guaranteed to fail every decoder immediately, so assert your complete validation requirements rather than only whether one inspection command exits successfully.

Exercise independent validation layers

Test transfer completion, byte-size bounds, content-type evidence, signature or decoder checks, expected dimensions or streams, and storage integrity separately. A header declaring video does not make HTML into a video. A nonempty file does not prove a transfer finished. A matching digest of a truncated file proves only that the same truncated bytes were copied.

Use a local HTTP fixture that advertises a larger Content-Length than it sends, returns an error document with HTTP 200, and interrupts the connection mid-body. Verify each scenario produces a delivery failure with safe diagnostic evidence and a retained staging manifest.

Test upload and publication boundaries

Make the storage adapter reject a checksum, return a failed upload, or report success just before the database manifest update fails. The artifact should remain unavailable until your application’s required verification and persistence steps finish. A deterministic destination key helps recovery inspect an existing upload without making another render.

Do not assume every storage ETag is a file checksum. Test the actual checksum mechanism your storage client supports and record the algorithm. When you perform a read-back comparison, compare the stored bytes with the verified staging evidence, not merely with a filename or an untrusted metadata field.

Preserve rendering state throughout

Your fixture should begin with a succeeded remote job and a known output identity. Every download or upload failure should leave that remote state unchanged. Save local delivery_failed or verification_failed state in your own operation schema, with a recovery action that targets the existing artifact.

Test an explicit user-requested regeneration separately. That is a new creation action with its own authorization and budget, not an automatic checksum repair.

Acceptance checks

Confirm zero-byte, wrong-type, truncated, and digest-mismatched fixtures cannot become public. Confirm a crash after upload can reconcile the same destination object. Assert the test suite makes no generation POST and requires no API key. Finally, verify logs identify the fixture and operation without exposing signed URLs or customer prompts.

See download validation, upload integrity, and range recovery.

Continue with production operations

Where these facts come from