daemon CLI crashes on media task failure (libuv `UV_HANDLE_CLOSING` assertion, exit -1073740791) — hides upstream error and empties stdout/stderr

[Bad-Fish666]

Summary

When a media task fails (e.g. an upstream 4xx, missing provider key, or unsupported parameter), the daemon CLI (media generate / media wait) prints the failure JSON and then crashes on exit with a native libuv assertion on Windows, returning a garbage exit code (-1073740791 = 0xC0000409) instead of a clean non-zero exit.

Because the process aborts, any harness that captures the CLI's stdout/stderr (redirect to a file, or $out = & node cli …) ends up with empty output — the buffered streams are lost. This makes a genuine upstream failure look like a "silent empty success" (exit 0/garbage, empty STDOUT/STDERR, no file written), which is very hard to diagnose and easily misattributed to the provider.

Environment

• Open Design 0.15.0 (packaged app)
• Windows x64, Node 24
• CLI: prebundled/daemon/daemon-cli.mjs (media generate / media wait)

Observed output (verbatim)

task <id> queued (running)
task failed: custom image 400: { … 'response_format' … }     # or: "no Fal API key — … set FAL_KEY"
{"taskId":"<id>","status":"failed","error":{ … , "status":400}}
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76
# process exit code: -1073740791  (0xC0000409)

Reproduced with two independent failure causes:

• media generate --model flux-pro-ultra … with no FAL_KEY → no Fal API key → crash.
• media generate --model gpt-image-2 --image ref.png … → upstream 400 (response_format, see companion issue) → crash.

The happy path does not crash: a successful gpt-image-2 text-to-image run exits 0 with the {"file":{…}} JSON and writes the PNG normally.

Steps to reproduce

1. Run any media generate that will fail upstream (missing key, unsupported param, 4xx).
2. Capture output, e.g. & $node $cli media generate … *> out.txt or $out = & $node $cli ….
3. The captured output is empty and the process aborts with the UV_HANDLE_CLOSING assertion instead of a clean exit 5 + preserved error JSON.

Expected

On task failure: clean exit code 5 (task failed) with the error JSON preserved on stdout/stderr. No native crash, no lost output.

Likely cause

An async handle (the SSE/poll socket or a stdout stream) appears to be closed twice / after the event loop is torn down on the failure branch on Windows (libuv uv_close on an already-closing handle). The success branch tears down cleanly; only the error/abort path trips the assertion.

Impact

• Masks all upstream provider failures behind an unhelpful crash + empty output.
• Breaks agent runtimes that rely on the documented contract (exit 0 with {file|taskId}, exit 5 on failure): the crash means the agent cannot distinguish "failed" from "produced nothing," and cannot surface the real error to the user.

[lefarcen]

Hi @Bad-Fish666 — thanks for the very clear repro; the contrast between the clean success path and the Windows-only failure path is especially helpful.

I checked the CLI wait path in apps/daemon/src/cli.ts together with the daemon task wait route. This does look like a real daemon CLI bug rather than a provider-specific error: the daemon /api/media/tasks/:id/wait path returns a normal JSON snapshot for failed tasks, but the CLI failure branch writes the failure JSON and then exits immediately on the same path. That fits your symptom much better than the upstream 400 itself, especially since you can trigger it with both the missing FAL_KEY case and the separate response_format issue in #5727.

So my current read is: this is a working hypothesis rather than a root-cause-confirmed fix yet, but the bug looks to be in CLI shutdown / output flushing on the failure branch, not in any one media provider. We’ll keep this tracked as a bug.

[stranger82]

Same silent-crash class via a different trigger: the daemon exits on a <question-form> (awaiting-input) turn — Linux, headless

We're hitting what looks like the same root cause as this issue (a process abort that empties stdout/stderr, so a genuine outcome looks like a silent empty exit), but from a different trigger and on a different surface: the long-running daemon (not the media CLI) aborts whenever a /api/chat turn ends with the driven agent emitting a renderable <question-form> (the awaiting-input flow). No media task is involved.

It's 100% reproducible and, notably, silent — no stack, no FATAL ERROR, nothing on stdout/stderr — exactly the "empty output" symptom described here.

Environment

• Open Design 0.14.2, headless daemon: node apps/daemon/dist/cli.js --no-open (PID 1 = tini -- node …).
• Linux x64, Docker (Alpine + gcompat/libc6-compat), Node 24.
• Driven agent: claude CLI pointed at a non-Anthropic model over an ANTHROPIC_BASE_URL bridge (GLM), streamFormat: claude-stream-json. The agent emits a valid renderable <question-form> (JSON body with a non-empty questions array) and the turn ends stopReason: end_turn — then the daemon exits.

Reproduction (curl)

BASE=http://127.0.0.1:7456
AUTH="Authorization: Bearer $OD_API_TOKEN"   # or run the daemon with OD_DISABLE_API_AUTH

# 1) create a project
PID=$(curl -s -X POST "$BASE/api/projects" -H "$AUTH" -H 'content-type: application/json' \
  -d '{"id":"repro-'"$RANDOM"'","name":"repro"}' | jq -r '.project.id')

# 2) a message that forces the agent to emit a question-form and NOT build
curl -sN -X POST "$BASE/api/chat" -H "$AUTH" -H 'content-type: application/json' -d '{
  "agentId":"claude","projectId":"'"$PID"'",
  "message":"You MUST ask clarifying questions first. Emit a <question-form id=\"discovery\"> whose body is JSON {\"questions\":[{\"id\":\"q1\",\"label\":\"Style?\"}]}. Do NOT build yet."
}'
# → the SSE stream ends abruptly mid-response
#   (curl: "transfer closed with outstanding read data remaining";
#    an httpx/undici client sees RemoteProtocolError / "incomplete chunked read")

# 3) the daemon process has exited — health is unreachable until it restarts
curl -s "$BASE/api/health"   # connection refused

Observed

• The /api/chat SSE stream carries the full turn (including the <question-form> and a final usage/stopReason: end_turn), then the connection closes uncleanly (incomplete chunked read).
• The daemon process exits immediately after. Under tini + --restart it comes back (exit code observed as 0); run standalone without a restart wrapper it stays down with exit code 1.
• Nothing is logged on stdout/stderr around the exit — no error, no stack, no FATAL ERROR. This is the same "hides upstream error and empties stdout/stderr" behavior reported here.

Ruled out (to save time)

• Not memory. Reproduces unchanged with NODE_OPTIONS=--max-old-space-size=768; the container cgroup peak was ~212 MB against a 1 GB limit; OOMKilled=false; host had multiple GB free; no kernel OOM events.
• Not an uncaught exception / fatal error. With NODE_OPTIONS="--report-uncaught-exception --report-on-fatalerror --report-dir=…", no diagnostic report is produced — so it's a handled/deliberate exit path (e.g. process.exitCode + drain, or a self-triggered shutdown), not a thrown-and-uncaught crash.
• Not load / a race with normal traffic. The daemon is stable across many ordinary (non-question) build turns; only turns that emit a <question-form> abort it, every time — including an isolated single-turn test on an otherwise-idle daemon.

Likely relationship

The distinctive "silent, emptied stdout/stderr" symptom is identical to this issue's, which points at a shared root cause — a native handle abort on the process-exit path (the UV_HANDLE_CLOSING shape) that tears the process down while output is still buffered. This issue's trigger is a failing media task; the trigger here is the awaiting-input / question-form completion path. If the fix generalizes to "never exit the process on a run/task terminal transition; flush and keep serving," it would likely cover both.

Expected

A run that ends on a <question-form> is a supported awaiting-input flow (the daemon even comments that such turns "legitimately close with code === 0 … the missing-artifacts guard must not treat it as a failure"). The daemon should transition the project to awaiting_input and keep serving, not exit.

Happy to provide more traces or test a patch — we build the image from source, so we can instrument if that helps pin the exact handle.

[lefarcen]

Hey @stranger82, this is extremely helpful — especially the repro showing the full <question-form> turn reaching stopReason: end_turn before the daemon disappears.

I checked the daemon-side awaiting-input path, and this new report changes my read a bit. The question-form flow is explicitly treated as a valid terminal turn in the daemon: server.ts buffers clarifying-form text so it does not get treated as a missing-artifact failure (apps/daemon/src/server.ts:5085-5097, 7529-7558), the DB layer marks projects with a latest assistant <question-form> as awaiting_input (apps/daemon/src/db.ts:755-796), and the display-status path maps that state to awaiting_input rather than failure (apps/daemon/src/server.ts:1207-1216). So this does not look like an intended "ask a form, then stop the daemon" behavior.

The other useful distinction is that I’m not seeing an obvious daemon-side equivalent of the media CLI’s direct process.exit(...) failure branch. In the headless startup path, the deliberate whole-process stop is the SIGTERM/SIGINT handler in apps/daemon/src/daemon-startup.ts:170-179, and the explicit in-repo trigger I found for that is /api/daemon/shutdown (apps/daemon/src/routes/daemon.ts:127-135). So right now my working hypothesis is: related symptom class, but probably a different path than the media wait crash — more like an unexpected process-level shutdown/signal after an otherwise valid awaiting-input turn.

If you’re up for one more targeted data point, the smallest high-signal check would be whether the daemon is receiving SIGTERM/SIGINT at the moment of exit, or whether /api/daemon/shutdown is being hit in the same window. If neither is true, that would narrow this further toward a lower-level post-turn abort rather than an intentional daemon shutdown.

[stranger82]

Thanks @lefarcen — did the targeted check. It's neither SIGTERM/SIGINT nor /api/daemon/shutdown; the daemon self-exits with exit_group(1) immediately after the agent child of the question-form turn exits cleanly.

I traced the daemon's node process across a crash: strace -f -tt -e trace=signal,exit_group -p <daemon_pid>, then triggered one question-form turn. At the moment of death:

<agent subprocess>  +++ exited with 0 +++
<daemon>  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_status=0} ---   # agent child exited CLEANLY
<daemon>  rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, …})                        # SIGCHLD handler reset
<node worker threads>  +++ exited with 0 +++   (× ~11, the libuv thread pool)
<daemon>  exit_group(1)   = ?                                                   # deliberate self-exit, code 1
<daemon>  +++ exited with 1 +++

Answering the two checks directly:

• No SIGTERM / SIGINT / SIGKILL / SIGABRT is delivered to the daemon. The only signal in the window is SIGCHLD from the agent subprocess exiting normally (si_status=0).
• /api/daemon/shutdown is not hit — we never call it, and there's no signal or shutdown-handler activity in the trace.

So it's not the intentional SIGTERM/SIGINT shutdown path. The daemon exits itself via exit_group(1) right after the child process that ran the question-form turn exits cleanly — i.e. a deliberate process.exit(1) / process.exitCode = 1 + event-loop drain on the child-close / post-turn path. That's also consistent with the earlier finding that --report-uncaught-exception/--report-on-fatalerror produces no diagnostic report (not a thrown-and-uncaught crash, not a native abort).

The silent exit code 1 (no log at all) fits a top-level serve() promise rejection caught by a .catch that sets process.exitCode = 1 without logging — the shape you flagged in the runDaemonCliStartup/serve tail. So the throw is likely happening in the awaiting-input child-close handling and bubbling to that top-level promise. Since our driven agent is a non-Anthropic bridge (claude-stream-json → GLM), the trigger may be specific to how that path finalizes a run that closes with a <question-form> and no artifact.

Happy to instrument further — we build the image from source, so if you point me at the serve .catch (or the child-close handler on the awaiting-input branch), I can wrap it to log the actual rejection and post the real error here.

[lefarcen]

Hey @stranger82, perfect — that rules out the intentional shutdown path very cleanly.

This new trace points to a more specific shape in the current daemon source: the chat-run child-close handler itself is async (apps/daemon/src/server.ts:7417), and that path does have awaited post-turn logic before finalization — including the question-form / empty-output branches we’ve been looking at (apps/daemon/src/server.ts:7529-7558). If something throws inside that async close handler after the child exits cleanly, it would surface as an unhandled rejection rather than as a normal agent failure.

And there’s a daemon-global fatal handler that matches your exit_group(1) observation almost exactly: apps/daemon/src/routes/telemetry.ts:165-179 installs process.on('unhandledRejection', ...), then triggerFatalShutdown() ends by calling process.exit(1) (apps/daemon/src/routes/telemetry.ts:160-163). That would explain all three things at once: clean agent child exit, no SIGTERM/SIGINT, and a silent daemon self-exit with code 1.

So my updated working hypothesis is: the question-form turn is not itself the problem — an exception is being thrown somewhere inside the child.on('close', async ...) post-turn finalization path, and the global unhandledRejection handler is what’s actually killing the daemon. If you’re instrumenting locally, the highest-signal place to wrap next is that child.on('close', async (code, signal) => { ... }) block in apps/daemon/src/server.ts, plus the unhandledRejection handler in apps/daemon/src/routes/telemetry.ts so it logs the rejection reason/stack before process.exit(1). If you capture that rejection text, please post it here — that should get us from symptom-class to the actual failing branch.

[stranger82]

Root cause captured — and it's avoidable. I teed od's fatal handler to a file (it currently ships the error to telemetry then process.exit(1), so it never reaches stderr — that's why the crash looked empty). One question-form turn logged:

[unhandledRejection] SqliteError: FOREIGN KEY constraint failed
    at upsertAgentSession (apps/daemon/dist/db.js:1099)
    at persistDeliveredAgentSessionState (apps/daemon/dist/server.js:4930)
    at ChildProcess.<anonymous> (apps/daemon/dist/server.js:6727)   # agent-child close

The FK is agent_sessions.conversation_id REFERENCES conversations(id) — it fails because the conversation_id has no row in conversations. On the agent child's close, persistDeliveredAgentSessionState() → upsertAgentSession() throws, and because that call isn't wrapped it's an unhandled rejection, which your routes/telemetry.js fatal handler turns into process.exit(1).

Crucially, the trigger isn't the question-form per se — it's a client-supplied conversationId that od never created a conversations row for. In our headless flow we were passing our own conversationId into POST /api/chat; od accepts it and sets run.conversationId, but no conversations row exists for it. A build turn happens to create the conversation along its normal path, but the awaiting-input/question-form turn reaches upsertAgentSession first, so the FK blows up. Your UI never hits this because it always creates the conversation before chatting.

Confirmed both directions:

• Question-form turn with a client conversationId (no conversations row) → FK error → daemon exits.
• Same turn without a conversationId (od creates the conversation) → closes cleanly, daemon stays up, and GET /api/projects/:id/conversations returns the id od assigned. So we just stopped supplying a client id and read od's back — crash gone on our side.

Two independent fixes that would harden od regardless of client behavior:

1. The FK cause: ensure a conversations row exists for run.conversationId before upsertAgentSession on this branch (e.g. upsert/insert-or-ignore the conversation when /api/chat is given a conversationId, or on the awaiting-input path), or skip the session upsert when the conversation isn't persisted yet.
2. The blast radius: wrap persistDeliveredAgentSessionState() at server.js:6727 (best-effort try/catch, log-and-continue). A DB error in child-close session persistence shouldn't be able to take down the shared daemon — right now any throw there is fatal via the unhandled-rejection handler, which is also why it was invisible (telemetry-only, then exit(1)).

That also explains the earlier signals: strace showed a self exit_group(1) right after the agent child's clean exit (this handler), and --report-uncaughtException produced nothing because the rejection is handled (telemetry → deliberate exit), not a native crash.

[lefarcen]

Hey @stranger82, this is excellent debugging — thank you. For the daemon / <question-form> path, this does look root-cause confirmed now.

The source lines match your trace very closely:

• /api/chat accepts a caller-provided conversationId and assigns it onto the run (apps/daemon/src/server.ts:4228-4249), but that path does not create a conversations row.
• The delivered-session persistence closure later calls upsertAgentSession(...) with that run.conversationId (apps/daemon/src/server.ts:5955-6005).
• agent_sessions.conversation_id has a hard FK to conversations(id) (apps/daemon/src/db.ts:92-109), so a never-persisted client conversation id will fail exactly the way you captured.
• That persistence call is invoked on the agent-child close path without a local guard (apps/daemon/src/server.ts:7929), so the throw can bubble into the daemon-global fatal rejection handler.

So I agree with your split: for this daemon/chat variant, the immediate cause is the missing conversations row for a client-supplied conversationId, and the daemon exit is the blast-radius bug. Also agreed that this now looks distinct from the original media wait crash even though the outward "silent exit / lost output" symptom rhymes.

Your workaround makes sense for headless clients today: don’t supply conversationId unless the conversation already exists in OD, and read back the OD-created id instead. On the OD side, the two hardening fixes you outlined are the right directions from what I can see in source as well: ensure/persist the conversation before session upsert, and make persistDeliveredAgentSessionState() best-effort so a DB-side persistence miss cannot take down the shared daemon. Thanks again for chasing this all the way to the FK.

[lefarcen]

PR #5808 is up to harden the daemon-side blast radius from the confirmed missing-conversation-row path above: it skips delivered-session persistence when the supplied conversationId has no stored conversation row, and wraps that child-close persistence so the turn can still finalize instead of taking the shared daemon down.

Keeping this issue open until #5808 lands and the broader symptom class is verified end-to-end.

[lefarcen]

Hey @Bad-Fish666 and @stranger82 — PR #5808 merged on July 17, 2026 and should cover the daemon /api/chat variant that @stranger82 root-caused above.

The change skips delivered-session persistence when a caller supplies a conversationId that does not have a stored conversations row yet, and it also wraps that child-close persistence so the shared daemon stays up instead of exiting on this path.

If either of you can re-test that headless /api/chat flow against a build containing #5808, please let us know whether the daemon now stays up and the awaiting-input turn completes cleanly.

Keeping this issue open for now because the original Windows media CLI UV_HANDLE_CLOSING failure from the issue body is still a separate symptom and is not covered by #5808.