[1.19.0 regression] Collecting a completed long-running subagent's result never resolves: foreground task await and background_output park forever (worked on 1.18.35) #54754

Description

Description

After upgrading to 1.19.0, any tool call that collects the result of a long-running
subagent parks forever:

• a foreground task call never resolves after the child finishes
• a background_output call never resolves when collecting a long-finished background task

The child subagent itself is healthy: it runs to completion, logs exiting loop, and its
transcript is fully persisted to storage. The parent's collector then simply never returns.
The server process stays alive and keeps serving other sessions; the parked run emits no
further log lines and no ERROR/WARN. Short collections (child ≤ ~9 min) still work.

On 1.18.35 the same operations always returned — with output truncated at ~50 KB when large,
but returned.

Environment

• OpenCode 1.19.0 (Desktop Electron app), Windows 11, Bun runtime
• occurred on two providers (zhipuai glm-5.3-flash and deepseek) — provider-independent
• oh-my-opencode plugin installed (tool.execute.after hook injects text into tool outputs)
• SQLite storage, ~3000 sessions

Evidence (from local SQLite storage, part table; sanitized export attached as evidence.json)

4 log-verified cases, all on 2026-10-12 (first working day after the app updated to 1.19.0):

DB signature of a parked collector: part row with state.status = "running",
state.time = {"start": ...} and no end, updated_at frozen at the call time, forever.

Controls on the same day / same version:

• foreground task with children of 4 s / 51 s / 552 s → returned fine
• run_in_background = true dispatches → tool returns in ~1 s regardless of child runtime
  (children of 10 / 20 / 33 min all finished); completion notification arrives fine —
  only the result collection is broken

Why this looks like a 1.19.0 regression

From the same storage, measured over the previous 14 days on 1.18.32–1.18.35:

• 206 foreground task calls, 0 hangs, longest successful foreground child
  1167 s (19.5 min) on 2026-10-08
• hundreds of background_output calls over 1.18.18–1.18.35, all returned
  (output truncated at ~50 KB with a marker, but always returned)

First day on 1.19.0: 3/3 long foreground calls hung, first background_output hang ever.

So on 1.18.x the collection path degraded gracefully (truncate-and-return); on 1.19.0 it
parks forever.

Distinguishing this from the known stream-hang family

This is not the "subagent stream hangs mid-run, no timeout" family (#11865 / #13841 /
#33028): in those, the child never finishes. Here the child completes (exiting loop
logged, transcript persisted) and only the collector parks — closer to #21250, but with a
clean version bisect (1.18.35 ok → 1.19.0 broken) and both the await path and the
background_output path affected.

Note: the same DB contains older stuck task parts from Aug–Sep (1.18.x) whose child never
logged exiting loop — those match the known stream-hang family and are excluded from
this report (listed separately in the attachment for completeness).

Workaround (validated)

Dispatch with run_in_background = true, and when the completion notification arrives, read
the artifacts from disk (files the child wrote, git log, evidence ledger) instead of calling
background_output. Validated today with a 20-minute child: no hang.

Suspicion (unverified)

oh-my-opencode's tool.execute.after hook runs at tool-result finalization, i.e. exactly at
the parking point; #39031 documents that a hook whose promise never settles parks the fiber
silently with no timeout. Worth checking whether 1.19.0 changed the hook/await ordering
around subagent result finalization.

evidence.json

Plugins

omo

OpenCode version

v1.19.0

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

windows11

Terminal

No response