Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Bug: Recursive loadConfig → console.warn → getLogger loop causes high CPU in v2026.3.24 [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#56290•Fetched 2026-04-08 01:42:43
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
0
Author
silvesterxmsilvesterxm
Participants
leonardo-bolanosleonardo-bolanossilvesterxmsilvesterxm
Timeline (top)
commented ×1

After upgrading from v2026.3.13 to v2026.3.24, the gateway process enters a recursive loop that causes sustained high CPU usage (47–143%). The gateway remains functional (messages route correctly) but burns CPU continuously.

Error Message

Failed to read config at ~/.openclaw/openclaw.json RangeError: Maximum call stack size exceeded at console.warn (env-D1ktUnAV.js:19611) at Object.loadConfig (env-D1ktUnAV.js:18880) at loadConfig (env-D1ktUnAV.js:19344) at readLoggingConfig (env-D1ktUnAV.js:19441) at resolveSettings (env-D1ktUnAV.js:611) at getLogger (env-D1ktUnAV.js:698) at getLoggerLazy (env-D1ktUnAV.js:19571) at console.warn (env-D1ktUnAV.js:19594) at Object.loadConfig (env-D1ktUnAV.js:18880) at loadConfig (env-D1ktUnAV.js:19344)

Root Cause

loadConfig() fails (likely AJV schema validation) → calls console.warn() to log the error → console.warn is monkey-patched to route through getLoggerLazy() → getLogger() calls resolveSettings() → readLoggingConfig() → loadConfig() → fails again → calls console.warn() → infinite recursion until stack overflow.

The config JSON itself is valid (parses cleanly with jq/Python json.load(), max nesting depth 7, 478 total keys, no circular references). The recursion is in the error handling path, not in the config data.

Fix Action

Workaround

None found — gateway continues to function but wastes significant CPU. Rolling back to v2026.3.13 should resolve it if needed.

Code Example

Failed to read config at ~/.openclaw/openclaw.json RangeError: Maximum call stack size exceeded
    at console.warn (env-D1ktUnAV.js:19611)
    at Object.loadConfig (env-D1ktUnAV.js:18880)
    at loadConfig (env-D1ktUnAV.js:19344)
    at readLoggingConfig (env-D1ktUnAV.js:19441)
    at resolveSettings (env-D1ktUnAV.js:611)
    at getLogger (env-D1ktUnAV.js:698)
    at getLoggerLazy (env-D1ktUnAV.js:19571)
    at console.warn (env-D1ktUnAV.js:19594)
    at Object.loadConfig (env-D1ktUnAV.js:18880)
    at loadConfig (env-D1ktUnAV.js:19344)
RAW_BUFFERClick to expand / collapse

Bug: Recursive loadConfig → console.warn → getLogger → loadConfig loop causes high CPU

Version

OpenClaw 2026.3.24 (cff6dc9) on macOS (Darwin arm64, Node v24.14.0 / v25.8.1)

Description

After upgrading from v2026.3.13 to v2026.3.24, the gateway process enters a recursive loop that causes sustained high CPU usage (47–143%). The gateway remains functional (messages route correctly) but burns CPU continuously.

Stack trace (from logs)

Failed to read config at ~/.openclaw/openclaw.json RangeError: Maximum call stack size exceeded
    at console.warn (env-D1ktUnAV.js:19611)
    at Object.loadConfig (env-D1ktUnAV.js:18880)
    at loadConfig (env-D1ktUnAV.js:19344)
    at readLoggingConfig (env-D1ktUnAV.js:19441)
    at resolveSettings (env-D1ktUnAV.js:611)
    at getLogger (env-D1ktUnAV.js:698)
    at getLoggerLazy (env-D1ktUnAV.js:19571)
    at console.warn (env-D1ktUnAV.js:19594)
    at Object.loadConfig (env-D1ktUnAV.js:18880)
    at loadConfig (env-D1ktUnAV.js:19344)

Root cause analysis

loadConfig() fails (likely AJV schema validation) → calls console.warn() to log the error → console.warn is monkey-patched to route through getLoggerLazy() → getLogger() calls resolveSettings() → readLoggingConfig() → loadConfig() → fails again → calls console.warn() → infinite recursion until stack overflow.

The config JSON itself is valid (parses cleanly with jq/Python json.load(), max nesting depth 7, 478 total keys, no circular references). The recursion is in the error handling path, not in the config data.

Reproduction

  1. Upgrade from v2026.3.13 to v2026.3.24
  2. Start gateway with a config that has agents, plugins, channels configured
  3. Observe RangeError: Maximum call stack size exceeded in logs
  4. ps aux shows gateway at 47–143% CPU

Version bisection evidence

  • v2026.3.13 (Mar 26 logs): 0 stack overflow errors across full day
  • v2026.3.24 (Mar 27 14:04 onwards): 419 errors in ~7.5 hours, continuing daily

Suggested fix

Guard the console.warn override in loadConfig error path to avoid re-entering loadConfig during error logging. For example, a reentrance flag or using the native console.warn (not the patched version) inside the error handler.

Workaround

None found — gateway continues to function but wastes significant CPU. Rolling back to v2026.3.13 should resolve it if needed.

extent analysis

Fix Plan

To resolve the recursive loop causing high CPU usage, we need to prevent re-entering loadConfig during error logging in console.warn.

Step-by-Step Solution:

  1. Introduce a reentrance flag: Add a flag to track whether loadConfig is currently executing to prevent recursive calls.
  2. Use native console.warn in error handler: Modify the error handling path in loadConfig to use the native console.warn instead of the patched version.

Example Code:

let loadConfigReentranceFlag = false;

function loadConfig() {
  if (loadConfigReentranceFlag) {
    // Handle reentrance, e.g., log an error and return
    return;
  }
  loadConfigReentranceFlag = true;
  
  try {
    // Original loadConfig logic here
  } catch (error) {
    // Use native console.warn to avoid recursion
    const nativeConsoleWarn = console.warn;
    console.warn = (...args) => nativeConsoleWarn(...args);
    console.warn('Error loading config:', error);
    console.warn = (...args) => getLoggerLazy().warn(...args); // Restore patched console.warn
  } finally {
    loadConfigReentranceFlag = false;
  }
}

Verification

To verify the fix, monitor the CPU usage of the gateway process after applying the changes. The CPU usage should return to normal levels, and the RangeError: Maximum call stack size exceeded errors should disappear from the logs.

Extra Tips

  • Ensure that the reentrance flag is properly reset after the loadConfig call to avoid false positives.
  • Consider adding additional logging to track any potential issues with the config loading process.
  • Review the getLoggerLazy and resolveSettings functions to ensure they do not introduce any other recursive loops.

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…
#request error#file not found#serialization error#model compatibility#GPU setup

Still need to ship something?

×6

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

Back to top recommendations

TRENDING