rendering errors & charged

[scottdraves]

user got a bunch of renders from the flow app that failed with this error:
https://alpha.infinidream.ai/dream/c0aaf0ca-9344-4d54-9e4e-5ce23eb6a0a4
https://alpha.infinidream.ai/dream/565c1cc7-b3f0-4af0-88bb-46976573a73d
https://alpha.infinidream.ai/dream/8392eef0-f11a-4ae3-a737-b157ac5564b0
https://alpha.infinidream.ai/dream/0d8ed999-44d9-4d24-a736-46e797dfaf01

the error is "Unprocessable Entity"
and user reports they were charged credits even though these jobs failed.
so there are two problems.

[scottdraves]

Dug into both halves. They're unrelated bugs, and the charging one is a real defect, not a reporting mistake — the user is right.

1. The charge is real: refundReservedDreamCost clears the reservation but never refunds

The arithmetic

The reporting user (caf3e4a5-…, Shiva Om) has dailyQuotaUsd = 10.0000 and providerCreditsUsd = 0.2000, in the window that began 2026-09-10T07:00Z. Their fal jobs in that window:

dream	model	dur	cost	ran for	result
b4061166	kling-i2v	15s	$1.68	354s	failed
74c88ae9	kling-i2v	15s	$1.68	329s	failed
0d8ed999	kling-i2v	15s	$1.68	405s	failed
565c1cc7	kling-i2v	15s	$1.68	355s	failed
8392eef0	kling-i2v	15s	$1.68	451s	failed
c0aaf0ca	kling-25-i2v	5s	$0.70	10s	failed
(1 other)	kling-25-i2v	5s	$0.70	—	processed

Failed: $9.10. Succeeded: $0.70. Total $9.80, and $10.00 − $9.80 = $0.20, which is exactly their balance. If the refunds had landed they would be sitting at $9.30. They were charged full price for six renders that produced nothing.

The cause

backend/src/utils/dream.util.ts:50

const rows = await dreamRepository.query(
  `UPDATE "dream" SET "reservedCostUsd" = NULL
   WHERE "uuid" = $1 AND "reservedCostUsd" IS NOT NULL
   RETURNING "reservedCostUsd"`,          // <-- always NULL
  [dreamUuid],
);

const reserved = rows[0]?.reservedCostUsd;
if (reserved != null && Number(reserved) > 0) {
  await refundProviderCredits(userId, Number(reserved));   // <-- never reached
}

Postgres RETURNING evaluates against the post-update row ("the expressions use the new values of the columns" — UPDATE docs). We just set the column to NULL, so RETURNING "reservedCostUsd" hands back NULL every time. reserved != null is false, and refundProviderCredits is never called.

The reservation gets cleared, so nothing looks wrong afterwards — the dream ends up failed with reservedCostUsd = NULL, exactly like a refunded one. Staging corroborates: zero failed dreams anywhere hold a live reservation, i.e. the UPDATE always runs and always wipes the evidence. The money just never goes back.

This affects every refund path, not only content-flag failures: handleSetDreamStatusFailed (dream.controller.ts:1329) and cancellation (dream.controller.ts:1912) both go through this function. Any failed or cancelled fal job since the credit system shipped (2026-06-23, 8be963f) has been charged in full.

Fix

Snapshot the old value instead of reading it back after the write:

UPDATE "dream" AS d
SET "reservedCostUsd" = NULL
FROM (SELECT "uuid", "reservedCostUsd" FROM "dream" WHERE "uuid" = $1 FOR UPDATE) AS prev
WHERE d."uuid" = prev."uuid" AND prev."reservedCostUsd" IS NOT NULL
RETURNING prev."reservedCostUsd" AS released

FOR UPDATE also closes the double-refund race two concurrent callers could otherwise hit.

Three things worth doing alongside it:

• A test that would have caught this. It needs a real Postgres — the bug is in SQL semantics, so a mocked query() returning [{reservedCostUsd: '1.68'}] passes against the broken code. Charge, fail, assert the balance is whole again.
• Reconcile the users who were already charged. Failed/cancelled fal dreams have already had reservedCostUsd nulled, so the amount has to be recomputed from prompt via calculateJobCostUsd to issue makegoods. Happy to write that script.
• Log the refund. Right now a refund that silently does nothing looks identical to one that worked. One APP_LOGGER.info with dream uuid + amount would have made this obvious.

Adjacent, smaller

• worker/src/workers/worker.factory.ts:60 — isUserCancellation substring-matches 'cancelled'/'canceled' anywhere in failedReason, which is arbitrary provider text. A cancelled job is deliberately never reported to the backend, so a false positive strands the dream in processing and keeps the charge. Worth tightening to our own sentinel regardless; it becomes a live risk the moment we start putting provider text into the error message (below).
• worker/src/services/video-service.client.ts:124 — if the POST /status/failed call itself fails, we only console.error. The dream sticks in processing and the reservation never releases. Needs a retry.
• Staging currently has 2 processed dreams holding a live reservation ($0.672), so handleSetDreamStatusProcessed doesn't always clear it either. Harmless for billing (a success should be charged), but it means the column isn't a trustworthy "outstanding reservation" flag for any reconciliation sweep.
• Separately, check what fal billed us. Those five kling-i2v jobs ran 5.5–7.5 minutes before being rejected, so the compute happened and fal very likely charged us for it even though the output was refused. The 2.5-turbo one died in 10s and probably cost nothing. That's our cost, not the user's, but it's worth knowing before we widen the daily quota.

2. "Unprocessable Entity": we throw away the reason

That string is not our error and it is not a malformed request. It is literally the HTTP 422 status text.

fal answers a rejected request with a body of {"detail": …} and no message. @fal-ai/client builds its Error as message: body.message || statusText (response.js:70), so detail — the only part that says anything — is dropped on the floor. worker.factory.ts:95 then forwards error.message to POST /dream/:uuid/status/failed, and that's what lands in dream.error and on the page.

For these dreams the fal console shows the real answer: the content checker flagged the request. The payload itself was fine — I validated it against fal's OpenAPI schema for both endpoints (prompt 1877 chars vs 2500 max, negative_prompt 734 vs 2500, duration in enum, cfg_scale in range, tail_image_url supported), and both source images fetch as valid 1920×1080 JPEGs. 256 structurally identical kling-25-i2v jobs have completed on stage. fal accepted and queued the submission; the rejection came from Kling on the way through.

Fix

I have this on fix/surface-fal-error-detail in this repo (not pushed):

• fal.provider.ts grows describeFalError, which pulls body.detail out of the thrown error — string form, or Pydantic [{loc, msg}] flattened to field: msg — and withFalErrorDetail wraps submit / status / result so it applies wherever the throw comes from. Unit tested, typecheck and build clean.
• worker.factory.ts gets the isUserCancellation tightening described above, since this change is what makes that latent bug reachable.

The dreams in this issue would then read:

fal rejected this request (HTTP 422): Content flagged by content checker

view-dream.page.tsx:formatDreamError passes non-JSON error text straight through, so no frontend change is needed for it to show up.

Worth going one step further

A raw provider string is a big improvement over Unprocessable Entity, but "Content flagged by content checker" still doesn't tell the user what to do. I'd map the known provider rejections to real copy — something like "Kling's content filter rejected this prompt or image. Try rephrasing the prompt or using a different start frame." — and keep the raw detail behind it for us.

That matters here beyond politeness: this user resubmitted the same flagged prompt five times at $1.68 each because nothing told them it would never work. Better copy is most of the mitigation for the quota burn; the refund fix is the rest.

---

Findings are from the deployed code on origin/main plus the live alpha API and the stage Redis/Postgres. I could not read the production database directly, so the charging conclusion rests on the balance arithmetic above rather than on inspecting the rows; the RETURNING semantics are from the Postgres docs (I was not able to demo it against a DB — even a rolled-back transaction is a write to shared staging).

🤖 Generated with Claude Code

https://claude.ai/code/session_01XkY5xXmYW1PNUfSCDG9yn6