A generated video still needs a receipt and a stopped runtime
A stale widget exposed separate completion checks for generation, media validity, byte receipt, engine shutdown, and runtime release.
The five-second video existed, but the embedded UI had not caught up. Its completion message and receipt field did not update, and its exit button remained disabled.
This happened in a private prototype running Wan2.2 TI2V-5B on an L4 in Google Colab. The useful result was more specific than “the tool worked”: generation, receipt, and runtime release each had separate evidence.
Inspect the existing job before submitting another
The trial generated one silent clip of a paper boat moving across water. It used Python 3.12.13, fixed dependencies, and model files whose hashes had been checked.
The worker had exited successfully. Rather than submit another generation, the operator used a helper path that read the existing job's state and exported its output. That recovered the MP4 and its settings JSON. The cause of the stale UI remains unconfirmed.
A button click, a completed worker, and a file received by the user are different events. A successful worker exit does not establish that the file reached the user.
A matching hash answers a different question from a valid video
The received MP4 was 571,335 bytes; its settings JSON was 2,301 bytes. Their sizes and SHA-256 hashes matched the generation-side receipt records.
That established byte identity. Media validation checked the requested output separately:
| Check | Recorded result |
|---|---|
| Video encoding | H.264 / yuv420p |
| Dimensions | 832 × 480 |
| Frame rate and count | 24 fps, 120 frames |
| Duration and audio | 5.000 seconds, no audio stream |
| Decode | All frames decoded without errors |
The generation graph handled 121 frames; the export used the first 120 to meet the receipt specification. The graph's frame count and the delivered file's frame count were recorded separately.
For this article, I checked that the current MP4 and settings JSON still match the saved receipt hashes. I did not rerun generation or the full decode. Successful decoding also does not establish the clip's overall visual or motion quality.
A stopped engine does not establish runtime release
The saved shutdown checks showed no remaining owned generation-engine process, a closed listening endpoint, and a successful worker exit.
Those checks did not establish that Colab had released the runtime. Automatic disconnection could not be confirmed after receipt verification, so the runtime was disconnected and deleted through Colab's normal menu. The resource panel then showed zero sessions, and the session manager was empty.
The interval from the pre-allocation clock to release confirmation was about nineteen minutes in this one trial. It is not a completion-time estimate for another model or environment.
Keep completion states small enough to prove
The trial supports five separate claims:
| Claim | Evidence |
|---|---|
| Generation finished | Successful worker exit |
| The output met the media specification | Media metadata and the saved full-decode check |
| The same output was received | Matching MP4 and settings sizes and hashes |
| The generation engine stopped | Owned-process and listening-endpoint checks |
| The runtime was released | Zero-session checks after normal deletion |
The UI's completion display, automatic shutdown, and continuous playback in a browser remain unverified or unresolved. Recovering a valid video is a narrower result than completing the entire GUI workflow.
This article draws on implementation and saved verification records. AI assisted development, verification, and the organization and writing of the article.