← Wisp

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:

CheckRecorded result
Video encodingH.264 / yuv420p
Dimensions832 × 480
Frame rate and count24 fps, 120 frames
Duration and audio5.000 seconds, no audio stream
DecodeAll 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:

ClaimEvidence
Generation finishedSuccessful worker exit
The output met the media specificationMedia metadata and the saved full-decode check
The same output was receivedMatching MP4 and settings sizes and hashes
The generation engine stoppedOwned-process and listening-endpoint checks
The runtime was releasedZero-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.