Skip to content
Guilherme Rohden
CasesCase 03
When a paid job is interrupted

Resume without repeating edits, and never charge for the same work twice

ResultA job restarted midway continued from where it stopped, with no duplicate edits and the same charge in all three records. Three jobs tried to reserve 2,400 credits at once from a 3,000 balance; exactly one got through.

In plain words
The problem
If an editing job crashes halfway, retrying from the top applies the same cut twice. And if several jobs each check the balance before any is charged, they can all spend the same credits.
What I did
The job now records each edit and saves its place immediately after applying it, before any optional review that might fail. Before any paid work starts, the credits are set aside under a lock, so two jobs cannot claim the same money.
What happened
In a restart test the job continued from the right place, every segment applied once, and the receipt, the job record and the ledger all showed the same 360 credits. In a concurrency test, one of three competing 2,400-credit reservations was admitted against a 3,000 balance.
My contribution

I set the recovery and billing requirements and delivered the implementation with coding agents.

An interrupted editing job does not mean nothing happened: a trim may already be in the timeline when a later review step fails, and retrying the whole step trims the video twice. HYVIRAL’s editing of long videos had to resume at segment boundaries, account for the edits already applied and keep its charges explainable. Credits are HYVIRAL’s prepaid units; a job is quoted a maximum before it starts and charged what it actually used.

What the assistant sees

The quote before any paid work

  1. The agent calls
    video_clean_talking_head({
  project_id: "…", captions: "bold", aggressiveness: "heavy"
})
  2. HYVIRAL quotes and runs nothing1
    "hyviral/requiresConfirmation": true,
"hyviral/quotedCredits": 35,
"hyviral/expiresAt": "2026-10-13T15:25:50Z"

    “You are charged what the call actually cost and never more than this.”

  3. The agent confirms
    video_clean_talking_head({ …same arguments, confirmationToken: "…" })
  4. A background job starts, credits held2
    "hyviral/jobStatus": "accepted",
"hyviral/reservedCredits": 35
  5. Delivered, charged what it cost3
    "status": "delivered",
"chargedCredits": 30
  1. 1Quoted before anything runs; the quote is a ceiling, not an estimate Decision 2
  2. 235 credits held before paid work starts, so concurrent jobs can’t spend them twice Decision 2
  3. 3The charge follows what actually ran, so the receipt has to record what applied Decision 1
The recovery boundaryApplied work and reviewed work are different states
  1. 1Apply edits

    The document changes.

  2. 2Write receipt

    Record what actually applied.

  3. 3Save the place

    A restart resumes after completed work.

    Progress recorded
  4. 4Optional review

    Add stills and review results to the receipt.

A failed review can no longer cause an edit to be applied twice.

Record the edit before a later, optional step can fail.

Decision 1

Save the applied work before the optional review

A failure on 5 September 2026 showed where recovery broke. A segment changed the document, but its review step timed out before the job saved its place; across four attempts the edit was applied repeatedly while the receipt would describe it once.

The fix writes the segment’s receipt entry and saves the job’s place immediately after the edits reach the document; preview stills and the optional review follow, and a later write adds their results. The receipt comes first because a resumed job skips the segments it has already completed.

The tradeoff: recovery may begin with incomplete review detail, since recording an applied edit does not certify its quality. The save is best-effort and not in the same transaction as the edit, so this closes the replay window we observed rather than guaranteeing exactly-once execution.

SourceImplementation + restart log

The ordering fix and the restart log: resumed at segment 2, segments 0 to 4 applied once each, 360 credits on the receipt, the job record and the ledger.

Read the source
Decision 2

Set the credits aside before admitting paid work

Several jobs can each read a sufficient balance before any charge lands, and if they all proceed they incur real provider costs against the same credits. Rejecting a charge afterwards is too late.

Billing now reserves credits before paid work proceeds. Placing a hold takes a database lock shared with the code that spends credits, so competing claims line up behind one balance decision; capture records the actual amount, and a failed charge rolls the hold back. Repeating a placement or a completed capture returns the first result.

The cost is lifecycle management: held credits are unavailable to other jobs, and failed or abandoned work needs its hold released or expired.

SourceSQL + concurrency test report

The database lock shared by reserving and spending credits, the capture path that rolls back on a failed charge, and the three-way concurrency test.

Read the source

Results

In a local restart test on 5 September 2026, the job resumed at segment 2 from a saved position naming segment 1. Segments 0, 1, 2, 3 and 4 applied once each, and the receipt, the job record and the ledger each recorded 360 credits against a 390-credit quote.

The recovery sweep picked the job up 499 seconds after the restart: a working recovery path with a measured delay.

In the database test reported in the 12 August specification, three concurrent requests to hold 2,400 credits against 3,000 available produced one admission and two denials.

From the restart log, 5 September 2026
resumedFrom=2 expected=2 (checkpoint lastApplied=1)sweep:resumed x1 at 2026-09-05T22:05:00.095Z → recovery 499s after the restartparts applied in order: [0,1,2,3,4] duplicates=[]MONEY restart quoted=390 receipt=360 row=360 ledger=360