fix(tools): surface taskId on subagent failure paths in task tool - #889
Conversation
Closes #886. Before: when the task tool rejected an agent because validate threw (agent.mode === 'primary'), the response only carried success: false and error. The parent agent had no taskId to feed back to task_status, even though taskStore.set() had retained the row. Failed subagents were effectively unrecoverable. After: a taskIdForFailure is bound before TaskTool.validate runs, so the validate-failure return now carries data.taskId, data.status = 'failed', data.completed = false, and data.agentId. The parent can then call task_status to inspect what went wrong, matching kilocode #11621. The background .catch handler already mutates taskData.status and taskData.error on the store, and task_status already surfaces both fields - added a test that exercises the round-trip. Tool description updated to advertise the new failure-id contract. [alexi-bot]
…on-update [autohealing]
Coverage Report
Coverage Details
|
SummaryPR #889 ( From an Architecture-vertical perspective this PR is clean: it does The findings below are the standing F1-F14 backlog from Re-verification result: every block-severity finding from the FindingsF0 --
|
Security review (role-security, automated)Scope: PR #889 ( SummaryNo Two Critical (block)None. High (warn)None introduced by this PR. (Repo-wide audit baseline shown under Infoi1. Echo-back of unvalidated The new i2. Subagent permission inheritance still TODO Pre-existing - NOT introduced by this PR - but called out because the i3. Repo-wide Lockfile unchanged in this PR, so this baseline is unchanged by the
Out of scope for this PR; track separately. Do NOT run Recommendations
Gate status (informational)
-- role-security, generated 2026-06-30 |
Architecture Review -- PR #889
SummaryPR #889 is a narrow The structural footprint is zero: no new top-level Verdict for this PR: no architectural concerns introduced. Approve from However, the broader repository state at this HEAD is essentially
This PR does not make any of those worse. None of the recommended FindingsA1 --
|
Review - role-quality
Scope verified
CorrectnessThe
Test mocks the registry BEFORE the tool import (vi.mock hoist + explicit ordering, per AGENTS.md). Temp state is cleared in Security / style
Minor observations (non-blocking)
Changes made: none. Verdict: Approved |
Closes #886.
Summary
Mirrors kilocode #11621 (merge
4a8f324, 2026-06-30). Thetasktoolused to swallow the task id whenever a subagent failed BEFORE producing
visible output, leaving the parent unable to call
task_statustorecover. This change surfaces
taskIdon the validate-failure returnand verifies the background
.catchround-trip via the store.Changes
src/tool/tools/task.tstaskIdForFailure = params.task_id ?? nanoid()BEFORE theTaskTool.validatecall so the id exists from the start of thefunction.
:202-205now carriesdata: { taskId, agentId, response: '', completed: false, status: 'failed' }in addition to
success: falseanderror.taskIdForFailureas the id of the freshly-inserted store row,so the id is stable across the validate boundary.
task_idcan also be used toinspect a failed task.
src/tool/tools/task_status.ts– no change needed. Already surfacestask.errorandtask.status(verified via new round-trip test).tests/tool/tools/task-failure-paths.test.ts– new file with threescenarios:
data.taskIdandstatus: 'failed'(uses avi.mockon../../src/agent/index.jsto force a primary-mode
exploreagent).task_idis preserved through validate-failure..catchround-trip: simulate the store mutation that thebackground
.catchperforms, then asserttask_statussurfacesboth
status: 'failed'anderror.Verification
Coverage: 62.36% lines (well above the 40% CI floor).
Source
Kilo-Org/kilocode#11621 —
+96 -4inpackages/opencode/src/tool/task.ts. Research brief:.github/research/2026-06-30-research.md(Detailed Finding #3).[alexi-bot]