The interesting engineering question isn't just how to call the model. It's what to do when a request times out and you don't know whether the provider accepted it.

Here's how I approached that in the current implementation, using TypeScript on Cloudflare Workers, D1 for job state, and R2 for media storage. This is a small-app design, not a claim of exactly-once execution across external services.

Give the inputs a stable meaning

The app generates an invisible motorcycle chase. Photo one supplies the rider; photo two supplies the chaser. A scene preset supplies a reference video and its matching audio.

That ordering is part of the input contract, not just a label in the interface. The server validates exactly two photo IDs and a known scene ID. In simplified form:

type JobInput = {
  requestId: string; // UUID, validated on the server
  photoIds: [string, string]; // rider, chaser
  sceneId: SceneId;
};

The generation instructions map image one to the rider and image two to the chaser. Keeping the same order from upload to provider request avoids an easy class of role-swapping bugs. It doesn't guarantee perfect identity preservation by the model, but it keeps the application itself unambiguous.

Persist the job before doing remote work

I store the validated inputs and provider request body in D1 before submission. The request ID is also the job ID.

When the same ID arrives again, the server returns the existing job only if the owner and normalized inputs match. Reusing that ID with different inputs is an error. The database insert handles conflicts, and the code reads the row back to verify it.

This covers a double click or a repeated browser request. It doesn't make the external provider idempotent, which is a separate problem.

The main path is:

queued → processing → composing → saving → succeeded

A confirmed failure can move the job to failed. An unknown outcome needs more care.

A timeout is not a rejection

Before submitting to the video provider, the worker records that submission has started. If it receives a task ID, it stores that ID and polls the existing task.

The awkward case is a lost response: the provider might have accepted the request, but the app never received its ID. Automatically submitting again could create another paid task.

For that case, the current implementation pauses for support review instead of issuing a fresh generation. It keeps the video allowance reserved. A definite rejection or confirmed generation failure can restore it.

That's an intentional tradeoff. Some users may wait for manual reconciliation, but a network timeout doesn't silently become permission to spend again. Browser-side deduplication alone wouldn't solve this.

Use leases, but fence late writes too

A worker claims a job with a time-limited lease. The claim also increments an attempts counter, used as a monotonic claim token.

A lease by itself isn't enough. A slow network request can outlive it. Another worker may take over while the first worker is still running.

Updates therefore check the job ID, claim token, unexpired lease, and allowed status. An old worker can't simply write a successful result after a newer claim has taken ownership. Output object keys include the claim token too, so a late upload doesn't overwrite the newer worker's object.

This protects database transitions and stored results. It doesn't magically make an external API side effect reversible; that's why the submission marker still matters.

Treat the webhook as a wake-up signal

The video callback contains a task ID and authentication information. After verification, the handler finds the corresponding job and makes it eligible for processing.

It doesn't trust callback fields as the final video result. The processing code asks the provider for the task's current state and output. A reconciliation pass also checks pending jobs, so recovery doesn't depend entirely on receiving a callback.

Retries use backoff with jitter. The important distinction is that these retries reconcile an existing task; they don't blindly create a replacement.

Audio and storage are separate stages

The video request asks for silent output. After that succeeds, a separate composition task adds the selected scene's audio. Only then does the app fetch and validate the finished video, save it to R2, and mark the job succeeded.

Splitting these stages means a storage problem doesn't need to restart video generation. It also makes “still processing” more useful internally: the job could be generating frames, composing audio, or saving the final file.

The audio service has the same uncertain-submission problem, so it gets its own submission marker and provider ID. I didn't assume that solving it once for video automatically solved it for the next service.

What I'd carry into another app

The lesson I keep coming back to is that “try again” needs a precise meaning. Retrying a status check, retrying a download, and creating another paid generation are different operations.

For a small AI app, a durable state machine and a conservative answer to unknown outcomes are worth more than a very optimistic retry button.

If you'd like to see the interface this supports, the project is at Crazy Frog AI Video Generator. I'd be interested in how other builders reconcile a provider submission when the response disappears and the provider offers no documented deduplication mechanism.

The app starts with one portrait. You choose the car and the location, and it generates the reveal sequence with you in the scene.

That is the whole premise. There is no prompt to write and no footage to film. I wanted to share what the app does and a little about the web application around it.

From a selfie to a reveal

The homepage has sample clips you can watch before signing in. Each sample has a short preview and a full 15-second version. For a tool like this, the movement matters as much as the final frame: you need to see the card gesture, the hand over the lens, and the transition into the car reveal.

If you want to make your own, sign in with Google and upload a clear portrait. A regular selfie is enough. You do not need to recreate the pose or find a car for the original photo.

There are three car options: a black SUV, a green supercar, and a red coupe. The setting is a separate choice: an underground garage, a rooftop parking area, or a city street. You can combine them in nine ways.

Once the video is ready, it appears in My videos, where you can watch it and download the file.

Keeping the app focused

The web app uses TanStack Start, React, and Cloudflare Workers, with an existing video generation service handling the footage.

My work is in the application around that service: the upload flow, the preset choices, generation job tracking, and access to the finished videos.

A small set of presets makes the workflow fairly easy to follow. Someone can watch an example, choose a car and a setting, then use their own photo. There is no need to explain camera instructions or ask them to describe a transition in a text box.

Generation also creates a different kind of interaction from a normal form submission. The user sends a request and waits for a result. Job tracking and a clear place to find the finished video are part of the product, even though the sample clip is what usually gets the attention.

What to expect from the file

The output is a 15-second, 16:9 MP4, with a 720p output setting. It is silent. The Unforgettable song is not included, so music needs to be added separately. A vertical version would also need a crop or a separate editing step.

The model generates new footage. Hands, facial details, clothing, and the exact timing can vary, so it is worth watching the whole clip before sharing it. The samples show the format; they are not a promise that every detail will match.

Watching the public examples is free. Creating a personal video requires a paid, one-time credit pack, without a subscription. A generation confirmed as failed returns its credit.

Uploads and finished videos are private to your account. Photos are retained for up to seven days and videos for 30 days, so download a copy of anything you want to keep.

You can see the examples at unforgettablecar.org.

If you try the flow, I would like to know whether the samples give you enough information before uploading a photo. That is the part I am most interested in getting right.

That leaves a short interface: sign in, upload a portrait, generate a video, then download it from My videos. The result is a 10-second, 720p, vertical MP4.

The interesting work is behind that short flow. A fixed scene removes a lot of choices from the screen, but a paid generation still has to survive retries, slow responses and partial failures.

Deciding what belongs in the form

For this scene, a prompt box would ask the user to describe something the reference video already shows. A duration selector would add another decision even though the performance has a prepared 10-second cut.

I kept the portrait as the variable input. It supplies appearance cues; the reference supplies the movement, framing and timing. The instructions target the main rapper and ask the model to preserve the surrounding people and scene.

That is the intended behavior, not a promise that every frame will match. Head turns, hands and interactions with the crowd still need reviewing. Keeping the input narrow makes it easier to explain the task, but it does not make generation deterministic.

Someone who wants a different performance will need a different workflow. I’m comfortable leaving that outside this app’s scope.

A video job has more than one finish line

The generated picture and the finished download are separate stages. The video request runs without generated audio. Once that stage succeeds, the app adds the prepared reference soundtrack and stores the resulting file.

The job record follows that sequence:

queued → processing → composing → saving → succeeded

A failure can happen after the model has produced a video: audio composition might fail, or storage might be temporarily unavailable. Marking the task complete as soon as the model returns would give the user the wrong answer.

I use a stored job record to keep track of the provider task, the audio step and the saved output. The download becomes available after the final file has been stored. Closing a tab does not remove that record; the user can come back to My videos.

Retrying a request should not buy another video

The app runs on Cloudflare Workers, with D1 for job and credit records and R2 for media. The generation endpoint takes a request ID alongside the uploaded photo ID.

If the same request arrives again with the same user and input, it returns the existing job. Reusing the ID with different input is rejected. A database trigger records the credit debit when the job is inserted, so the debit belongs to the job creation rather than a separate browser request.

This covers retries at the app boundary. It does not make the external provider’s submission exactly-once.

The awkward case is a timeout after sending the provider request. A missing response does not tell me whether the provider accepted it. Sending a fresh request could create a second video and a second provider charge.

The implementation records that submission has started before making the call. If there is no task ID afterward, the job stays under review instead of being submitted again blindly. Its credit remains reserved while the outcome is checked.

That is less convenient than an automatic retry button. It also gives a more honest answer about what the app knows.

A confirmed failure is different from an uncertain result

A confirmed failed job returns its generation credit. The ledger uses a unique reference for that return so repeating the failure handling does not add another credit.

An uncertain submission is not yet a confirmed failure. And a completed video whose likeness the user dislikes is not the same thing as a failed task. These cases need different messages, even if all three feel like “it didn’t work” to someone looking at the screen.

I put those distinctions in the creation guide and pricing page. There are no free generations; credits are sold in one-time packs. A new accepted task uses a credit, including another version made with the same photo.

Showing the limits before the upload

The homepage has the motion reference, so someone can watch the scene before spending a credit. The gallery examples are credited clips from outside creators, not outputs from this service. They show the trend; they do not establish what every generated result will look like.

The site also states its file windows: uploaded photos are kept for up to seven days, and finished videos for 30 days. Users should download the clips they want to keep and use portraits they have permission to upload.

I wanted the first screen to be small. Making it small still meant writing the less exciting parts: input checks, job state, credit handling and clear descriptions of an uncertain outcome.

You can see the app at bulin47.online. If you build apps around paid generation APIs, I’d be interested in how you handle the gap between “the request timed out” and “the provider definitely rejected it.”