Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Bug: sub-agent announce fails with 400 BAD_REQUEST after task completion [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#72575•Fetched 2026-04-28 06:34:16
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
0
Author
ecicanecican
Participants
ecicanecicansahilsatralkarsahilsatralkar
Timeline (top)
commented ×1

When a sub-agent (dev-agent, re-agent, ui-agent, etc.) completes a task and attempts to announce the result back to the parent agent via the built-in announce mechanism, the announce request consistently fails with 400 BAD_REQUEST. This happens across ALL sub-agents and has been occurring since at least 2026-03-05.

Error Message

AxiosError: Request failed with status code 400 code: ERR_BAD_REQUEST

Root Cause

When a sub-agent (dev-agent, re-agent, ui-agent, etc.) completes a task and attempts to announce the result back to the parent agent via the built-in announce mechanism, the announce request consistently fails with 400 BAD_REQUEST. This happens across ALL sub-agents and has been occurring since at least 2026-03-05.

Fix Action

Workaround

As a temporary workaround, sub-agents are being configured to send completion results directly via Feishu messages to the main agent, bypassing the broken announce mechanism. However, this is not a proper fix.

Code Example

AxiosError: Request failed with status code 400
code: ERR_BAD_REQUEST

---

[warn] Subagent announce give up (retry-limit) run=<run_id> child=agent:<agent>:subagent:<subagent_id> requester=agent:main:feishu:direct:ou_xxx retries=3 endedAgo=13s

---

Subagent completion direct announce failed for run <run_id>: AxiosError: Request failed with status code 400
RAW_BUFFERClick to expand / collapse

Bug Report: sub-agent announce fails with 400 BAD_REQUEST after task completion

Description

When a sub-agent (dev-agent, re-agent, ui-agent, etc.) completes a task and attempts to announce the result back to the parent agent via the built-in announce mechanism, the announce request consistently fails with 400 BAD_REQUEST. This happens across ALL sub-agents and has been occurring since at least 2026-03-05.

Expected Behavior

sub-agent should successfully notify parent agent upon task completion via the announce mechanism, and the parent agent should receive the completion event.

Actual Behavior

The announce request fails with:

AxiosError: Request failed with status code 400
code: ERR_BAD_REQUEST

Retries (up to 3) also fail with the same error. A fallback to sendThreadCompletionFallback never triggers (confirmed: 0 occurrences in logs).

Log Evidence

From gateway.log:

[warn] Subagent announce give up (retry-limit) run=<run_id> child=agent:<agent>:subagent:<subagent_id> requester=agent:main:feishu:direct:ou_xxx retries=3 endedAgo=13s

From gateway.err.log:

Subagent completion direct announce failed for run <run_id>: AxiosError: Request failed with status code 400

Statistics: 99 occurrences in logs across multiple days, ALL sub-agents affected.

Technical Analysis

The failure occurs in subagent-announce-delivery module:

  1. sendSubagentAnnounceDirectly() calls callGateway({method: "agent", ...})
  2. This WebSocket call goes to the minimax provider
  3. The request includes inputProvenance: {kind: "inter_session", sourceTool: "subagent_announce"}
  4. minimax returns 400 on this specific request type

Key observation from logs: The first announce attempt sometimes succeeds (✓), but subsequent retries within the same task consistently fail. The failure pattern suggests the issue is triggered by the idempotencyKey or inputProvenance in retry requests.

Environment

  • OpenClaw: 2026.4.24 (cbcfdf6)
  • macOS: Darwin 25.3.0 (arm64)
  • Node: v25.6.1
  • Model: minimax/MiniMax-M2.7-highspeed
  • Channels: feishu (multiple bot accounts)

Workaround

As a temporary workaround, sub-agents are being configured to send completion results directly via Feishu messages to the main agent, bypassing the broken announce mechanism. However, this is not a proper fix.

Suggested Investigation

  1. Check if minimax WebSocket API rejects requests with inputProvenance.kind === "inter_session" after the first successful attempt
  2. Investigate whether the idempotencyKey with announce: prefix causes issues on retry
  3. Check if there's a rate limit or request size limit being hit on announce retries

This bug breaks the entire sub-agent completion notification system and significantly impacts multi-agent workflow reliability.

extent analysis

TL;DR

The most likely fix involves modifying the sendSubagentAnnounceDirectly() function to handle the idempotencyKey and inputProvenance correctly, potentially by regenerating the idempotencyKey for retries or adjusting the inputProvenance to avoid minimax API restrictions.

Guidance

  • Investigate the minimax WebSocket API documentation to understand the restrictions on inputProvenance.kind === "inter_session" and how it affects subsequent requests.
  • Verify if the idempotencyKey with the announce: prefix is causing issues on retries by checking the minimax API logs or testing with a different key format.
  • Consider implementing a retry mechanism that regenerates the idempotencyKey or adjusts the inputProvenance for subsequent attempts to avoid minimax API restrictions.
  • Check for any rate limits or request size limits on the minimax API that could be causing the retries to fail.

Example

// Example of regenerating idempotencyKey on retry
const regenerateIdempotencyKey = (originalKey) => {
  // Logic to regenerate the key, e.g., appending a retry counter
  return `${originalKey}-retry-${retryCount}`;
};

const sendSubagentAnnounceDirectly = () => {
  // ...
  const idempotencyKey = 'announce:initial-key';
  const inputProvenance = { kind: 'inter_session', sourceTool: 'subagent_announce' };
  
  // Initial attempt
  callGateway({ method: 'agent', idempotencyKey, inputProvenance });
  
  // On retry, regenerate the idempotencyKey
  const regeneratedKey = regenerateIdempotencyKey(idempotencyKey);
  callGateway({ method: 'agent', idempotencyKey: regeneratedKey, inputProvenance });
};
``

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#installation#tensor shape#autograd error#model save/load

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING