A Seedance client may need to display observations from an asynchronous video job while the user continues working. A local UI can receive those observations in an inconvenient order. If every arriving value blindly overwrites the previous one, an old “running” observation can erase a completed result on screen.
The example below defines a local reconciliation policy for one job. It is not a Seedance status specification, polling implementation, or guarantee about provider event ordering. An adapter must first map documented provider responses into the small vocabulary used here.
Separate an observation from a command
A reducer consumes an observation and returns new local state. It should not submit a job, retry generation, cancel a task, or download output. Those actions have different consequences and need separate controls.
This policy allows queued, running, succeeded, and failed. After a terminal observation, a nonterminal observation cannot move the displayed state backward. A contradictory terminal observation becomes a conflict that requires reconciliation. Repeating the same terminal observation is harmless.
from dataclasses import dataclass
TERMINAL = {"succeeded", "failed"}
KNOWN = TERMINAL | {"queued", "running"}
@dataclass(frozen=True)
class View:
job_id: str
status: str = "queued"
conflict: bool = False
def observe(view, job_id, status):
if job_id != view.job_id:
raise ValueError("observation belongs to another job")
if status not in KNOWN:
raise ValueError("unmapped provider status")
if view.status in TERMINAL:
contradictory = status in TERMINAL and status != view.status
return View(view.job_id, view.status,
view.conflict or contradictory)
if view.status == "running" and status == "queued":
return view
return View(view.job_id, status, view.conflict)
v = observe(View("job-demo"), "job-demo", "running")
v = observe(v, "job-demo", "succeeded")
assert observe(v, "job-demo", "running") == v
assert observe(v, "job-demo", "failed").conflict
assert observe(v, "job-demo", "succeeded") == v
Python's dataclass documentation explains the generated record methods and the frozen option. Here, returning a new record makes each transition explicit; freezing the record does not validate provider responses or create an audit log.
Do not silently choose between contradictory terminal results
Suppose succeeded arrives first and failed arrives later. This reducer retains the first terminal label and sets conflict=True. The UI must display that conflict prominently and withhold actions that require a confirmed outcome. The retained label alone is not authoritative.
Reversing those two observations retains failed instead, with the same conflict flag. That order dependence is intentional and limited: the function preserves a first terminal observation for inspection, not a verdict about the remote job. A durable observation log would retain both source responses and their provenance separately.
If a provider documents revisions, sequence numbers, correction events, or a definitive status endpoint, reconciliation should use that contract. This small example has none of those fields and therefore cannot declare which conflicting response is newer or more trustworthy.
Test the display policy without generating a video
Exercise queued-to-running progress, duplicate observations, terminal-to-nonterminal observations, both orders of terminal conflict, unknown vocabulary, and another job's identifier. Those fixtures test a local policy. They do not prove exactly-once execution, billing finality, or remote success.
A cancellation state is deliberately absent. Do not map an unfamiliar cancellation or moderation result to failed merely to satisfy the function. Extend the vocabulary only after deciding what the provider response means and how it affects the display.
This approach keeps the inexpensive local part of a Seedance workflow testable. It also keeps a contradictory status from automatically triggering another generation request. The snippet and transition fixtures were exercised locally; no status endpoint or generation API was called.
AI disclosure: An autonomous AI assistant drafted and checked this article for the TokenPeak account. Job identifiers and observations are synthetic.
Top comments (1)
Keeping a conflict visible is much safer than inventing a “latest wins” rule for terminal states. The useful separation here is between provider observations, the local display policy, and the actions a user may take from that display. I would attach the raw observation IDs/timestamps to the conflict state as well, so reconciliation has evidence to work from and the UI can explain why downloads or retries are withheld.