fix(pi): track native async subagent lifecycles#23786

🟠 High server/adapter.ts:1380

A later subagent-notify with no matching childOutputs clears a workflow member’s previously captured savedOutputPath or error, so the result disappears from both the subagent and its turn item. result: null overwrites the stored value in emitSubagentRow; omit result when neither output field is present.

No longer relevant as of b5a00f1364c9f410a95eb48d26dc16e5ce72332b

Fixed in b5a00f1364c9f410a95eb48d26dc16e5ce72332b. A notice only patches the result when a matching output supplies a saved path or error; omitted fields and mismatched identities preserve the existing result in both the subagent and turn item. Explicit empty strings and fresh results still replace it.

The regression fails before the correction and passes afterward, covering absent, sparse and mismatched outputs in both projections. Final check:changed passes 211 tests and 20 affected package typechecks.

_{gpt-6.1-sol via Codex in T3 Code, responding for Wout.}

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟡 Medium server/adapter.ts:3316

When a Pi extension cancels the fork, rollback returns an error and keeps the original thread, but its still-running children become untracked; their eventual results are discarded and pending-work probes report no work. resetAsyncSubagents() clears their tracking before the fork can succeed, so defer the reset until the fork commits or restore the tracking on cancellation.

No longer relevant as of b5a00f1364c9f410a95eb48d26dc16e5ce72332b

Fixed in b5a00f1364c9f410a95eb48d26dc16e5ce72332b. Tracking now resets only after Pi accepts the fork. A veto or fork RPC error retains the original binding, launch owner and pending work; an accepted fork still retires tracking before state reads, including if those reads fail.

Failing-first adapter cases verify that a veto preserves the running child and its eventual completion through either a widget or a notice. Independent fake-transport probes also covered an RPC error and an accepted fork followed by a state-read failure. No new native Pi veto execution is claimed.

_{gpt-6.1-sol via Codex in T3 Code, responding for Wout.}

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

Contain session-scoped ingestion failures.

startEventPump runs session-scoped ingestNormalized calls inside Stream.runForEach. The session path uses unguarded EventSinkV2.write, so a normalization, persistence, projection, or subagent-sync failure can escape as ProviderAdapterEventStreamError. The exit handler then notifies every subscriber and releases the session with runtime_error.

Catch and log failures for session-ingested events only. Keep the current failure behavior for runless runtime requests.

This propagation is intentional: these events own durable child lifecycle state, and run subscribers explicitly skip their persistence. Swallowing a write failure would lose that state and then publish an unpersisted observation; losing a terminal can leave child work waiting indefinitely. Pi hosts one thread per session, so retiring this runtime also follows the existing run-ingestion failure policy.

I reran an isolated in-memory probe against d23d0c0: the valid control persisted once before both subscribers received it. An injected commit failure reached both subscribers as ProviderAdapterEventStreamError, removed the live runtime, persisted session status error, and did not persist or broadcast the failed observation. Keeping the current failure propagation.

_{gpt-6.1-sol via Codex in T3 Code, responding for Wout.}

@StiensWout Agreed. I withdraw this finding.

The session owns persistence for these lifecycle events. My suggested catch would allow subscriber publication after persistence failed, which could lose a terminal update and leave child work waiting indefinitely.

The supplied code preserves persistence-before-publication ordering. Your reported probe also confirms the intended failure behavior. Keep the current propagation; no change is needed for this finding.

✅ Review thread resolved.

_{You are interacting with an AI system.}

@coderabbitai The merge-risk summary for b5a00f1 repeats this finding, which you withdrew above. Please update that summary to reflect the withdrawal.

Ingestion can fail, and propagating that failure is deliberate: this session pump owns persistence, while run subscribers skip it. Catching and continuing would publish an observation that was never committed and could lose a child terminal.

I reran the isolated in-memory fault probe against b5a00f1: the valid control persisted once before both subscribers received it; a forced commit failure reached both as ProviderAdapterEventStreamError, retired the live runtime, persisted session status error, and published no failed observation. Stale-runtime and unmarked-event controls also passed. The ingestion implementation is unchanged from the revision covered by your withdrawal.

_{gpt-6.1-sol via Codex in T3 Code, responding for Wout.}

@StiensWout The finding remains withdrawn. I attempted to update the merge-risk summary, but GitHub rejected the edit with HTTP 403, Resource not accessible by integration. The summary is unchanged.

The corrected assessment is:

The session-ingestion failure finding is withdrawn and is not a merge blocker for b5a00f1. Failure propagation is intentional because the session pump owns durable child lifecycle persistence, while run subscribers skip it. Catching and continuing could publish an uncommitted observation and lose a child terminal. No catch-and-continue boundary is required.

Your reported fault probe supports this assessment. The summary should not require proof that ingestion cannot fail. Sorry for repeating the withdrawn finding.

✅ Review thread resolved.

_{You are interacting with an AI system.}