You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 950f606
Browse filesBrowse the repository at this point in the historyBrowse files
|`state_file`| str \| null | Path of the job state file (poll with `comfy jobs status`) |
507
+
|`state_file`| str \| null | Path of the job state file (poll with `comfy jobs status`); null when no record could be written — see [below](#known-limit-a-state-file-failure-is-never-a-run-failure)|
508
508
509
509
`cached_node_ids` and `executed_node_ids` may overlap: a cached
510
510
output-bearing node emits both `execution_cached` and `executed`. Agents
@@ -521,6 +521,39 @@ the same on both targets, `watcher_spawned` included (add `--where cloud` to
521
521
the follow-up commands for a cloud job). The async envelope carries no
522
522
`outputs_by_node` / `outputs_by_item` / `warnings` — nothing has run yet.
523
523
524
+
### Known limit: a state-file failure is never a run failure
525
+
526
+
Writing the job's state file is best-effort on an **async submit** (the default,
527
+
no `--wait`, local or cloud) and on **local `--wait`**. If the state directory
528
+
can't be written — a config root that resolved somewhere unreachable, a
529
+
read-only or sandboxed home, a full disk — the run still reports `ok: true`,
530
+
because by then the server has already accepted the prompt. What the envelope
531
+
says depends on the path, and `data.state_file` is `null` on both:
532
+
533
+
-**async submit** — `data.status: "queued"`, exactly as it would be with the
534
+
record written.
535
+
-**local `--wait`** — the run goes on to completion in the foreground and
536
+
finishes `data.status: "completed"` with its outputs, so a failed state write
537
+
costs you only the on-disk record, not the result.
538
+
539
+
**`state_file: null` is not a failed run**, and in particular it is not a
540
+
transport error: there is nothing to retry, and re-submitting queues a second
541
+
job for a prompt that is already running. Follow an async job by `prompt_id`
542
+
(`comfy jobs status <prompt_id>`) and treat a missing record as "unknown", not
543
+
"did not run".
544
+
545
+
With no record there is also nothing for a background watcher to update, so the
546
+
spawn is skipped and `data.watcher_spawned` is `false` — poll
547
+
`comfy jobs status` yourself, as that field already instructs.
548
+
549
+
Run with `LOG_LEVEL=DEBUG` to see the swallowed cause.
550
+
551
+
**Cloud `--wait` is not yet covered.** That path still writes its state record
552
+
directly, including inside its own error handlers, so an unwritable state
553
+
directory there can surface as a traceback after the job was accepted rather
554
+
than as a clean envelope. Treat the guarantee above as scoped to the paths
555
+
named in the first paragraph.
556
+
524
557
### Known limit: `--wait` has no background watcher
525
558
526
559
`--wait` writes the job's state file at submit and finalizes it in the
0 commit comments