Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Feature]: MCP bundle materializer needs exponential backoff for rate-limited server init [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#74183•Fetched 2026-04-30 06:27:40
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
kai-the-man[bot]kai-the-man[bot]
Participants
clawsweeper[bot]clawsweeper[bot]kai-the-man[bot]kai-the-man[bot]
Timeline (top)
commented ×1cross-referenced ×1

Error Message

bundle-mcp failed to start server "cloudflare": Error: Streamable HTTP error: Error POSTing to endpoint: {"error":"temporarily_unavailable", "error_description":"Rate limited, try again later"}

Code Example

bundle-mcp failed to start server "cloudflare": Error: Streamable HTTP error: 
Error POSTing to endpoint: {"error":"temporarily_unavailable",
"error_description":"Rate limited, try again later"}
RAW_BUFFERClick to expand / collapse

Feature Request

OpenClaw's MCP bundle materializer (pi-bundle-mcp-tools.ts) does not implement exponential backoff when MCP server initialization fails with rate-limit errors. This causes rapid-fire retry loops that burn through rate-limit quotas.

Problem

When a streamable HTTP MCP server (e.g. Cloudflare MCP at https://mcp.cloudflare.com/mcp) returns 429 Too Many Requests or temporarily_unavailable, the bundle-mcp subsystem retries immediately on the next session that needs it. With no backoff, this creates a loop:

  1. Session A tries to use Cloudflare MCP → server init fails with temporarily_unavailable
  2. 30 seconds later, Session B tries → fails again
  3. After ~15 attempts, the server returns invalid_token (quota exhausted)
  4. Logs show 48+ failed attempts in a single day

Evidence

bundle-mcp failed to start server "cloudflare": Error: Streamable HTTP error: 
Error POSTing to endpoint: {"error":"temporarily_unavailable",
"error_description":"Rate limited, try again later"}

48 occurrences on 2026-04-29 alone.

Expected Behavior

MCP server initialization should use exponential backoff with jitter:

  • Initial retry: 5s
  • Max retry: 5 minutes
  • Max attempts: 5 per server per hour
  • Backoff should apply per-server, not per-session

Actual Behavior

Every session that needs the MCP server triggers a fresh initialization attempt with no backoff. Rate limits are hit within minutes.

Environment

  • OpenClaw: 2026.4.23
  • MCP transport: streamable-http
  • Affected server: Cloudflare MCP (but applies to any HTTP MCP server with rate limits)

Related Issues

  • #59711 — Configurable retry backoff for API rate limit (LLM providers, not MCP)
  • #5159 — No exponential backoff on 429 rate limit errors (LLM providers)

Suggested Implementation

In src/agents/pi-bundle-mcp-tools.ts around line 213 (failed to start server handler):

  1. Track per-server last-failure timestamp and attempt count
  2. Before init, check if server is in cooldown
  3. Apply exponential backoff: min(300, 5 * 2^attempts) seconds
  4. Reset attempt count after successful init
  5. Log backoff events at info level

This is similar to existing LLM provider backoff (#49834) but applied to MCP server lifecycle.

extent analysis

TL;DR

Implement exponential backoff with jitter in the MCP bundle materializer to prevent rapid-fire retry loops when encountering rate-limit errors.

Guidance

  • Modify the pi-bundle-mcp-tools.ts file to track per-server last-failure timestamp and attempt count.
  • Implement a cooldown check before initializing the server to prevent immediate retries.
  • Apply exponential backoff using a formula like min(300, 5 * 2^attempts) seconds to gradually increase the delay between retries.
  • Reset the attempt count after a successful server initialization to allow for a new retry cycle.

Example

// Example exponential backoff implementation
const getBackoffDelay = (attempts: number) => {
  return Math.min(300, 5 * Math.pow(2, attempts));
};

// Usage
const attempts = getAttemptCountForServer(serverId);
const delay = getBackoffDelay(attempts);
setTimeout(() => {
  // Retry server initialization
}, delay);

Notes

The suggested implementation is similar to the existing LLM provider backoff, but applied to the MCP server lifecycle. This change should help prevent rate-limit quotas from being burned through due to rapid-fire retry loops.

Recommendation

Apply the workaround by implementing exponential backoff in the MCP bundle materializer, as this will help prevent rate-limit errors and reduce the number of failed attempts.

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#API rate limit#output truncation#response parsing#generation error

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 [Feature]: MCP bundle materializer needs exponential backoff for rate-limited server init [1 comments, 2 participants]