Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug] memory-core Dreaming causes RangeError: Maximum call stack size exceeded during JSON Schema compilation (AJV) [1 pull requests, 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#61951•Fetched 2026-04-08 03:10:49
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
1
Author
glorydu-byteglorydu-byte
Participants
glorydu-byteglorydu-byte
Timeline (top)
cross-referenced ×2subscribed ×1

Error Message

[plugins] google failed to load from C:\Users\Glory\AppData\Roaming\npm\node_modules\openclaw\dist\extensions\google\index.js: RangeError: Maximum call stack size exceeded [plugins] minimax failed to load from C:\Users\Glory\AppData\Roaming\npm\node_modules\openclaw\dist\extensions\minimax\index.js: RangeError: Maximum call stack size exceeded

Root Cause

Possible Root Cause

Fix Action

Workaround

None confirmed yet. Disabling google/minimax plugins would break agents that depend on these providers.

PR fix notes

PR #61980: fix(plugins): prevent reentrant stack overflow in resolveProviderPluginsForHooks during plugin loading

Description (problem / solution / changelog)

Summary

  • Problem: The openclaw dashboard crashes with RangeError: Maximum call stack size exceeded during startup or when certain plugins trigger repeated loads. The stack trace points to a deep synchronous recursion involving normalizeProviderConfigWithPlugin and loadOpenClawPlugins.
  • Root Cause: The recursion is caused by a reentrant cycle during plugin loading. When validateConfigObject applies model defaults via materializeRuntimeConfig, it calls normalizeProviderSpecificConfig for each provider. This triggers normalizeProviderConfigWithPlugin, which calls resolveProviderPluginsForHooks. If the cache is empty and there is no active registry, it calls loadOpenClawPlugins with activate: false and cache: false. During the module evaluation of these plugins (via jiti), top-level code or register() callbacks can indirectly trigger another config read or provider normalization, re-entering resolveProviderPluginsForHooks before the first load finishes. Because cache: false prevents caching the intermediate registry, this forms an infinite synchronous loop until the stack overflows.
  • Fix: Added a reentrancy guard (resolvingProviderPluginsForHooks) in resolveProviderPluginsForHooks. If the function is called while already resolving plugins, it safely returns an empty array to break the cycle. This check intentionally sits after the cache lookup so that already-cached provider keys are still served correctly during reentrant resolution. The outer call will then complete normally and populate the cache, allowing subsequent lookups to succeed without recursing.
  • What changed:
    • src/plugins/provider-runtime.ts: Added resolvingProviderPluginsForHooks boolean flag and wrapped the resolvePluginProviders call in a try/finally block to manage the guard state.
    • src/plugins/provider-runtime.test.ts: Added a strict regression test that mocks a reentrant call to normalizeProviderConfigWithPlugin during plugin resolution to ensure the guard breaks the cycle and prevents RangeError.
  • What did NOT change (scope boundary): The core plugin loading logic (loadOpenClawPlugins), config validation (validateConfigObject), and registry caching mechanisms remain unchanged. The fix is strictly scoped to the provider hook resolution path where the recursion occurs.
  • Note on other stack overflow issues: This PR specifically fixes the synchronous reentrant cycle described above. It does not address stack overflows caused by deep AJV schema compilation (e.g., when loading plugins with massive oneOf branches like google or minimax), which is a separate issue related to AST generation depth.

Related Issues

Fixes #61922

Changed files

  • src/plugins/provider-runtime.test.ts (modified, +48/-0)
  • src/plugins/provider-runtime.ts (modified, +35/-11)

Code Example

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 */6 * * *"
          }
        }
      }
    }
  }
}

---

[plugins] google failed to load from C:\Users\Glory\AppData\Roaming\npm\node_modules\openclaw\dist\extensions\google\index.js: RangeError: Maximum call stack size exceeded
[plugins] minimax failed to load from C:\Users\Glory\AppData\Roaming\npm\node_modules\openclaw\dist\extensions\minimax\index.js: RangeError: Maximum call stack size exceeded
RAW_BUFFERClick to expand / collapse

Bug Description

When running openclaw memory promote --apply or when the Dreaming cron job triggers, memory-core attempts to load google/minimax plugins, which in turn triggers compilation of a very large JSON Schema (AJV). This causes RangeError: Maximum call stack size exceeded during schema validation code generation.

Steps to Reproduce

  1. Install memory-core plugin: openclaw plugins install memory-core
  2. Enable dreaming in config:
{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 */6 * * *"
          }
        }
      }
    }
  }
}
  1. Run openclaw memory promote --apply
  2. Observe: RangeError: Maximum call stack size exceeded

Expected Behavior

Dreaming should execute normally, promoting short-term memories to long-term memory.

Actual Behavior

Process crashes with stack overflow during AJV schema compilation. The error occurs deep in the AJV validation code generation phase.

Environment

  • Host OS: Windows_NT 10.0.26200
  • Node.js: v24.14.0
  • npm: 11.9.0
  • OpenClaw: 2026.4.5 (3e72c03)
  • Plugins: google, minimax, feishu (loaded), memory-core (installed)

Error Log

[plugins] google failed to load from C:\Users\Glory\AppData\Roaming\npm\node_modules\openclaw\dist\extensions\google\index.js: RangeError: Maximum call stack size exceeded
[plugins] minimax failed to load from C:\Users\Glory\AppData\Roaming\npm\node_modules\openclaw\dist\extensions\minimax\index.js: RangeError: Maximum call stack size exceeded

Stack trace shows the error originates in AJV's schema compilation when processing deeply nested oneOf/anyOf/allOf schema structures.

Possible Root Cause

The google/minimax plugins contain JSON Schema definitions with excessive oneOf branching (100+ alternatives). When AJV compiles these schemas into validation functions, the generated code exceeds Node.js default stack size during execution.

Workaround

None confirmed yet. Disabling google/minimax plugins would break agents that depend on these providers.

Impact

  • Dreaming feature is unusable
  • memory-core cannot function when google/minimax are enabled
  • Affects all agents using Google or MiniMax model providers

extent analysis

TL;DR

Increase the Node.js stack size to mitigate the RangeError: Maximum call stack size exceeded issue when loading google/minimax plugins.

Guidance

  • Identify the maximum call stack size limit in Node.js and consider increasing it using the --stack-size flag or node_options configuration to accommodate the deeply nested JSON Schema definitions.
  • Review the JSON Schema definitions in the google/minimax plugins to optimize or simplify the oneOf/anyOf/allOf structures, reducing the complexity and potential for stack overflows.
  • Consider disabling the google/minimax plugins temporarily to isolate the issue and verify if the problem persists without these plugins.
  • Investigate AJV configuration options to optimize schema compilation and validation, potentially reducing the likelihood of stack overflows.

Example

No specific code snippet is provided, but an example of increasing the Node.js stack size using the --stack-size flag could be: node --stack-size=1024 index.js

Notes

Increasing the stack size may only be a temporary workaround, and a more permanent solution would involve optimizing the JSON Schema definitions or improving AJV's handling of deeply nested schemas.

Recommendation

Apply workaround: Increase the Node.js stack size to mitigate the issue, as this is a relatively simple and non-invasive change that can help alleviate the problem while a more permanent solution is explored.

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…
#batch processing#GPU compatibility#latency issue#model loading#dependency 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