Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug] Subagent completion notification loop causes excessive API calls [1 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#43802•Fetched 2026-04-08 00:17:57
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
lkk66lkk66
Participants
lkk66lkk66

Root Cause

The notification acknowledgment mechanism appears to have a bug where:

  • Parent response is not recognized as "acknowledgment"
  • System continues to treat the task as "unprocessed"
  • Retry logic triggers repeated notifications

Fix Action

Fix / Workaround

  1. Create a cron job with sessionTarget: "isolated" and delivery.mode: "none"
  2. Use sessions_spawn to dispatch subagents
  3. When subagent completes, system sends completion notification to parent
  4. Parent agent responds with acknowledgment
  5. Bug: System does not recognize the acknowledgment and resends the notification
  6. This creates a loop: notification → response → resend → response → ...
{
  "id": "cron-job-id",
  "agentId": "main-brain",
  "sessionTarget": "isolated",
  "delivery": {
    "mode": "none"
  },
  "payload": {
    "kind": "agentTurn",
    "message": "Dispatch subagents..."
  }
}

Workarounds Tried

Code Example

{
  "id": "cron-job-id",
  "agentId": "main-brain",
  "sessionTarget": "isolated",
  "delivery": {
    "mode": "none"
  },
  "payload": {
    "kind": "agentTurn",
    "message": "Dispatch subagents..."
  }
}
RAW_BUFFERClick to expand / collapse

Bug Description

When using sessions_spawn with delivery.mode: "none", the subagent completion notification gets repeatedly sent to the parent agent, causing an infinite loop of API calls.

Environment

  • OpenClaw version: 0.1.8-fix.3
  • Model provider: Bailian (Qwen3.5-plus)
  • Session target: isolated

Steps to Reproduce

  1. Create a cron job with sessionTarget: "isolated" and delivery.mode: "none"
  2. Use sessions_spawn to dispatch subagents
  3. When subagent completes, system sends completion notification to parent
  4. Parent agent responds with acknowledgment
  5. Bug: System does not recognize the acknowledgment and resends the notification
  6. This creates a loop: notification → response → resend → response → ...

Observed Behavior

Case 1: Stock Trading Agents (main-brain)

  • Impact: 100+ API calls consumed in ~3 minutes
  • Frequency: Notification resent every 3-5 seconds
  • Pattern: Same subagent completion notification repeated 10+ times

Case 2: Community Evolution Agent

  • Impact: 442,208 tokens consumed
  • Same pattern: Subagent completion notification loop

Expected Behavior

After parent agent responds to the completion notification, system should:

  1. Mark the notification as "processed"
  2. Not resend the same notification
  3. End the session gracefully

Actual Behavior

System repeatedly resends the completion notification regardless of parent response, causing:

  • Excessive API call consumption
  • Session bloat
  • Potential rate limiting

Configuration Example

{
  "id": "cron-job-id",
  "agentId": "main-brain",
  "sessionTarget": "isolated",
  "delivery": {
    "mode": "none"
  },
  "payload": {
    "kind": "agentTurn",
    "message": "Dispatch subagents..."
  }
}

Workarounds Tried

  1. Reply with short text instead of NO_REPLY - ❌ Did not work
  2. Disable cron jobs - ✅ Stopped the bleeding but lost automation
  3. Add duplicate detection in agent logic - ⚠️ Partial mitigation

Root Cause Analysis

The notification acknowledgment mechanism appears to have a bug where:

  • Parent response is not recognized as "acknowledgment"
  • System continues to treat the task as "unprocessed"
  • Retry logic triggers repeated notifications

Impact

  • Cost: Significant API call waste (100+ calls in minutes)
  • Reliability: Cannot use cron + spawn pattern reliably
  • User Experience: Manual intervention required to stop loops

Suggested Fix

  1. Fix notification acknowledgment recognition
  2. Add deduplication logic at framework level
  3. Provide option to disable completion notifications entirely
  4. Add circuit breaker to prevent infinite loops

Additional Context

This issue affects any agent using:

  • Cron jobs with sessionTarget: "isolated"
  • Subagent dispatch via sessions_spawn
  • delivery.mode: "none" configuration

Thank you for looking into this critical issue! 🦞

extent analysis

Problem Summary

Infinite retry of sub‑agent completion notifications when a parent session is created with

"delivery": { "mode": "none" }

The parent’s acknowledgment is never marked as processed, so the framework keeps resending the same notification.

Root Cause (brief)

The notification dispatcher treats every incoming AgentTurn as a new task because:

  1. No unique identifier is attached to the completion event.
  2. The acknowledgment handler only checks payload.kind === "ack" and that the turnId matches a pending turn stored in the in‑memory queue.
  3. With delivery.mode: "none" the turn is never persisted, so the pending‑turn entry is missing → the ack is ignored → retry loop.

Fix Plan

1. Add a stable notificationId to every sub‑agent completion turn

// src/agents/notification.ts
export interface CompletionNotification {
  notificationId: string;   // UUID v4
  parentSessionId: string;
  subAgentId: string;
  status: "completed";
  payload: any;
}

When sessions_spawn finishes, generate the ID:

import { v4 as uuidv4 } from "uuid";

function sendCompletion(parentId: string, subId: string, result: any) {
  const notif: CompletionNotification = {
    notificationId: uuidv4(),
    parentSessionId: parentId,
    subAgentId: subId,
    status: "completed",
    payload: result,
  };
  enqueueNotification(notif);   // goes through the same delivery pipeline
}

2. Persist processed IDs (lightweight store)

Create a new table/collection processed_notifications (key = notificationId, value = timestamp).
If you already have a Redis cache, use

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#ssr#installation#tensor shape#autograd error#API rate limit#retriever error#indexing error#inference speed

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug] Subagent completion notification loop causes excessive API calls [1 participants]