How to Retry After a DramaFork Video Failure: First Determine Whether It's the Prompt, the Asset, or the Task Status
After a video task fails, first record the task and the original prompt, then check the input version, and decide whether to modify the related storyboard or reference before retrying separately.
Introduction
After a video task fails, first record the task and the original prompt, then check the input version, and decide whether to modify the related storyboard or reference before retrying separately. First distinguish two situations: the task did not return a usable video, and a video was already returned but the content does not match. The former checks the actual error and status; the latter checks whether the visuals match the input. This article is compiled by DramaFork. Below, fictional shots are used to demonstrate the inspection method, and the constructed phenomena are not treated as real platform errors or success-rate records.
Step 1: Write the failed object as one line
Before retrying, first write clearly which asset task failed, rather than "the video failed." It is recommended to record four items: the task name, the storyboard or character it depends on, the input version used this time, and the exact error message shown in the interface. The error message should be copied verbatim, not rewritten into your own understanding, because rewriting will lose the stage it points to.
The fictional project "Mist Harbor Night Talk"'s "Dock Look Back_03" uses storyboard v4 and character reference v2. When recording, the actual interface message should be copied; no platform error code is invented here. If the task is completed but the visuals are wrong, write "the clip was returned, and the look-back action differs from expectations," and separately list the expected action. This way, a content quality issue will not be mistakenly recorded as the service rejecting the request.
Step 2: Sort into three categories by error message
Different messages point to different stages. Categorize first before acting, which can avoid changing the wrong place.
| Inspection clue | Possible cause to check | Where to check first |
|---|---|---|
| Clip content does not match, or the actual message involves input | Action text is vague or self-contradictory | Storyboard description and this task's input |
| Character identity or clothing does not match expectations | The reference used an inapplicable version | The corresponding character or style reference |
| No result returned, and the actual message involves timeout or service | Service and task status issues | The original prompt, whether the current task is still running |
Categorizing only narrows the scope; it does not mean the message is necessarily accurate. Prompt constraints do not guarantee correct output every time, so after categorizing, a manual check is still needed.
Step 3: Conflict troubleshooting in the constructed case
Return to "Dock Look Back_03." Suppose a clip has already been returned, the action does not match, and the author finds that the same storyboard sentence requires the character both to face the sea and to face the camera directly. This is a contradiction in the input itself, so the text can be changed first. A front-facing character reference does not automatically conflict with a back-facing shot; a conclusion cannot be drawn based only on the reference's orientation.
| Check item | Current content | Whether there is a conflict |
|---|---|---|
| Storyboard action | Both facing the sea and facing the camera directly | Camera position is undefined, and the action requirement is vague |
| Character reference image | Shen Yan_Default v2, standing front-facing | Check identity and clothing first; do not judge as wrong based only on orientation |
| Style reference | Cool-toned night scene | Unrelated to the action, leave it unchanged for now |
| Input version | Storyboard v4 + Shen Yan_Default v2 | Records are consistent |
In this example, first change the action to "the character stands facing the sea, then turns back to look at the person coming ashore," clarifying the camera's relative position and the ending orientation. Keep the character reference and do not replace all inputs at once. If the actual failure message is unrelated to the action, this table cannot be used to prove the cause; continue checking the stage the message points to. The troubleshooting record stores the phenomenon, hypothesis, and this change, and does not write the hypothesis as a verified cause.
Step 4: Change only the relevant input, then retry the corresponding asset
After confirming the conflict, the change should fall on the relevant input. In this example, the storyboard action can be changed to make "looking back with the back to the camera" clearer; a character reference image with a matching orientation can also be swapped in. After changing, record the new version, such as "storyboard v5 + Shen Yan_Default v2," then retry only the single task "Dock Look Back_03."
This involves the real downstream relationships of the workflow: changing the storyboard affects nodes, video, preview, and export; changing the character affects video, preview, and export. Therefore, after changing the storyboard, only mark the relevant completed steps as needing update, and keep the old data. There is no semantically precise automatic diff, and no one-click confirmation reuse; creators must manually check whether this change altered the expression of the old asset. Do not rerun all videos in the entire project just because one storyboard was changed.
Step 5: When to stop repeated retries
Retrying is not an infinite loop. If any of the following occurs, it is recommended to stop and first return to the input layer for troubleshooting, rather than continuing to click retry:
- The same error message appears more than twice in a row, and the input version has not changed.
- All check items in the troubleshooting table are marked "no conflict," but the message still points to an asset conflict.
- You begin explaining the failure by inventing character motivations, rather than changing the prompt or asset.
- The task status shows an anomaly, but you repeatedly retry without first confirming the status.
Stopping repeated retries does not mean giving up; it means changing the action from "click again" to "check the input again." What this step saves is the confusion caused by repeatedly rerunning the entire project.
Completion check
After one round, use these items to confirm whether it is truly resolved:
- The failed object has been recorded as one line, including task name, dependency, input version, and original error text.
- The error has been categorized into one of the three types: prompt, asset, or task status.
- The conflict troubleshooting table has been filled in item by item, without explaining it by inventing settings.
- Only the relevant input was changed, and the new version number was recorded.
- Only the corresponding asset task was retried, without unconditionally rerunning the entire project.
- The relevant downstream steps are marked as needing update, and the old data is still retained.
If all six items are satisfied, this retry is well-founded. The next time a video failure occurs, first write that one-line record, then decide what to change.
