Vhoo.ai is an AI image and video creation service with reference-based generation and reusable templates. This engineering note from the Vhoo.ai team explains how its application separates upstream generation from storing a result users can retrieve. AI assisted the writing; the implementation details were checked against the current project source. No new benchmark or load test was run for this article.
Two different meanings of completion
In Vhoo.ai, a generation provider can report a completed video while the application still needs to retrieve the file and copy it into its own storage. A successful model run answers “Did the provider generate media?” The product also needs to answer “Do we have a stored result to attach to this user's task?” Treating those questions as identical can expose a download action before the application's persistence work has finished.
Vhoo.ai stores the generation task in D1 and generated media in R2. The task carries both an application ID and the provider's task ID. When polling reports completion, the application extracts a video URL, rejects a result that contains no video, persists the media, and only then updates the local task to completed with its stored URL and object key. If the provider supplies a thumbnail, the current flow persists that before the task update as well.
Make the order explicit
The Vhoo.ai video completion path follows this sequence. This is a description of the flow, not a complete implementation to paste into an application:
query the provider recorded on the task
read the completed video's URL
require a non-empty video result
stream the media into application storage
persist the supplied thumbnail, if present
update the active task with stored URLs and object keys
mark the task completed
For Vhoo.ai, this ordering means a media download or storage failure occurs before the local completed update. The interface should not interpret upstream success alone as proof that the application has a usable saved file. Keeping the application's task active until persistence succeeds also preserves the distinction between generation work and result-delivery work, even when both appear under one loading state.
Stream the file instead of buffering the entire video
Vhoo.ai's media persistence helper passes the fetched response body to the R2 write operation. It does not first turn the complete video into an in-memory byte array. This avoids deliberately buffering the whole output in the Worker before starting the storage write. The helper also checks the response and supported media content type before choosing the stored file extension. The supported inputs for R2's write method are documented in the Cloudflare R2 Workers API reference.
Vhoo.ai retains an R2 object key alongside the public result URL in its task record. Those values serve different purposes: the URL is useful for playback and downloads, while the key identifies the object in application storage. Keeping both makes later storage operations possible without attempting to reconstruct an object key from a public-facing URL.
Guard the database transition
Vhoo.ai's completion update is scoped to the task ID, its owner, and an active status such as pending, submitted, or processing. A response from a poll that started earlier should not unconditionally overwrite a task that has already moved to a terminal state. An update condition communicates which transitions the writer is still allowed to make.
Vhoo.ai's database guard does not turn the entire provider-download-storage-database sequence into one transaction. Two pollers can still start persistence work before either updates the task, and a successful object write can precede a failed database write. That is a useful boundary to state plainly: protecting a database transition and preventing every repeated external operation are separate problems.
Review failure boundaries, not just the happy path
For a Vhoo.ai-style generation service, useful verification cases include a provider reporting success without a result URL, a failed source download, an unsupported media type, an R2 write failure, and overlapping poll responses. Another case is successful video persistence followed by failed thumbnail persistence, because the current completion path waits for both when a thumbnail is supplied. These are review and test scenarios suggested by the flow, not claimed results of tests performed for this post.
Vhoo.ai's main architectural lesson here is to define completion at the point where the application has recorded its saved result. The provider's status is an input to that decision. The application still owns the work between that status response and the video that appears in a user's history.
Product context
Vhoo.ai applies this asynchronous generation flow to image and video tools. One example is the Car Jump AI Video Generator, which accepts a portrait and a vehicle photo for a fictional stunt video. The template defines the creative inputs; the task and storage layers handle how the generated result becomes available to the user.
Top comments (0)