anomalyco / anomalyco/opencode

Sub-agent Task silently returns empty result when the final response stream fails (e.g. 503) — no error, no retry, completed work lost

Open
#40,527 3 comments 0 reactions 1 assignee View on GitHub

@jlongster is already working on this.

Since Aug 4, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Description

When a sub-agent (Task) finishes all its tool work but its final response stream then
fails — e.g. server [503] The request queue is full — the parent Task call returns an
empty result. No error is surfaced and no retry happens; the sub-agent's completed work
is silently discarded.

Reproduced on two explore sub-agents in one parent session (opencode 1.18.13). Both
completed 64 and 52 tool calls (data mining against a 151 MB DB), then hit [503] on
their last message (msg_fce23bb9..., msg_fce2648...). Both returned an empty
<task_result> to the parent. The work was only recoverable by re-extracting the
sub-agents' persisted tool outputs directly from opencode.db.

This is the known 503/free-tier overload family (#40254, #38051, #39276). The client-side
part I'm reporting is that a Task whose final stream dies should surface the stream error
to the parent (and/or retry), not return a success-looking empty result.

Plugins

@cortexkit/opencode-magic-context (context management); GitHub MCP; atomic-updater MCP

OpenCode version

1.18.13

Steps to reproduce
  1. Start a Task (subagent) with a long multi-tool mining workload (many sqlite3/bash calls).
  2. Hit a provider overload window so the final response stream fails with [503] ....
  3. Observe: sub-agent completes all tool calls, final stream errors, sub-agent result is empty.
  4. Parent receives empty result; no error shown; no retry; the mined data appears lost.
Screenshot and/or share link

No response

Operating System

Linux (Qubes OS 4.2.4) - Under Fedora (FC37) Standalone VM

Terminal

OpenCode TUI (CLI) - under Konsole

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.