Repository navigation
[Bug]: Async pi-subagents workflow, chain and parallel runs never appear in the subagent UI #17564
Description
Activity
Updating this against current upstream: pi-subagents 0.77.0 (published 2026-10-10T05:26Z, nicobailon/pi-subagents#2797) attaches structured
detailsto the completion notice:details: { runs: [ { runId, agent, status, source, durationMs, asyncDir, handoffPath, workflowRunId, workflowReceiptPath, childRuns[], childOutputs[], taskInfo, scheduleOrigin, reconciledFromDetachedChild, watchdogBlockers[], sessionLabel/sessionValue } ] }Verified locally on 0.77.0 (
src/runs/background/notify.js~L458-464, withrunIdadded at ~L627).This closes the "the completion carries no identity" half of the problem described above: a workflow completion can now be attributed to its children through
workflowRunIdpluschildRuns[]instead of by parsing notice text. Two limits remain:details.runsarrives only when the notice is sent, so it cannot produce the initial running rows for a workflow, chain orruns.all([...])launch — those still need the launch receipt or thesubagent-asyncwidget snapshot.- fix(provider-pi): show async pi-subagents runs as running subagents #17393 covers the single-launch case only, so a workflow launch would still project nothing even with the new ids available.
The ask is unchanged: track the workflow/chain/parallel projection gap, with the widget snapshot as the live-state source and the new
details.runsas the settlement source.
Before submitting
Area
packages/provider-pi(Pi adapter projection). The single-run case is #17363; this is the workflow/chain/parallel case, which is explicitly out of scope there.Steps to reproduce
subagenttool withruns.all([...]), a chain, orworkflowScript, rather than oneasync: truelaunch.Expected behavior
The launched children appear as running subagents, the way a single async launch does once #17393 lands.
Actual behavior
Nothing is projected. The adapter still requires the synchronous result shape (
toolName === "subagent"plusdetails.results[]entries carryingagentandtask), and a workflow launch returnsThe completion then arrives as a
subagent-notifycustom message that pi-subagents labels differently from the single-run case, so text matching cannot settle these runs.#17393 states this directly in its scope section: "Parallel, chain, and workflow async launches still show nothing, because pi-subagents labels their completion differently."
Evidence is from source inspection of the adapter and pi-subagents 0.76.1 rather than a hand-recorded UI trace; the replay fixture in #17393 shows the single-run projection failing on
mainfor the same underlying reason.A data source that already covers this
pi-subagents already publishes a bounded, versioned snapshot over RPC that contains the whole tree, so no new upstream data is strictly required:
extension_ui_request/method: "setWidget", widget keysubagent-asyncPI_SUBAGENT_ASYNC_JSON:kind: "pi-subagents.async-status-snapshot",version: 1, withruns: [{ id, kind: "subagent" | "workflow" | "step", label, state, startedAt, updatedAt, endedAt, activity: { state, currentTool, ... }, children: [...] }]and explicitcaps/omittedboundsVerified in pi-subagents 0.76.1 (
src/runs/shared/async-status-projection.d.ts). States map cleanly onto the adapter's subagent statuses (queued -> pending,running -> running,complete -> completed,failed/partial/rejected -> failed,paused -> idle,stopped -> interrupted).Prior art for a reader exists in a public fork:
kevinsleegerslameco/t3codebranchcodex/pi-subagent-background-proofadds aPiSubagentSnapshot.tsthat parses this widget into nested rows and emitssubagent.updated(written against the pre-packages/provider-pipaths, so it needs porting).Request
Track the workflow/chain/parallel gap so it is not silently closed by #17393. Happy to help with a port of the widget-snapshot reader if that is the shape you want.