RPC error: RangeError: Maximum call stack size exceeded

[kchro3]

I continue to see this type of error:

✘ [ERROR] RPC error: RangeError: Maximum call stack size exceeded

      at Bl.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:276:25)
      at null.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:277:21)
      at Bl.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:276:25)
      at null.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:277:21)
      at Bl.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:276:25)
      at null.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:277:21)
      at Bl.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:276:25)
      at null.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:277:21)
      at Bl.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:276:25)
      at null.<anonymous>
  (file:///.../node_modules/agents/src/index.ts:277:21)

It happens intermittently and not in an easily reproducible way. It has been reported a few times in the Discord channel. Would like to request that the withAgentContext is not autowrapped. This makes it even harder to trace what is causing the failures, and I think it should be opt-in via decorator if I want to call getCurrentAgent

[kchro3]

The best i can gather is that my @callable does something like: messages.filter((m) => this.filterMessage(m));

I think that this could be causing a deeply nested chain of withAgentContext's

[kchro3]

here's what Claude says btw:

⏺ Based on my analysis of the agents library source code, I've identified the root
  cause of the infinite loop and maximum call stack exceeded error. Here's what's
  happening:

  Root Cause Analysis

  The issue occurs due to a circular dependency in the autowrap custom methods
  functionality. Here's the problematic sequence:

  1. Constructor Calls _autoWrapCustomMethods(): When your <redacted> is
  instantiated, the constructor calls this._autoWrapCustomMethods() at
  /Users/.../agents/packages/agents/src/index.ts:387
  2. Autowrap Detects <redacted>: The _autoWrapCustomMethods() function scans
  the prototype chain and finds <redacted> as a custom method (since it's
  decorated with @callable() and not in the base Agent/Server prototypes)
  3. Creates Wrapped Function: It creates a wrapped version using withAgentContext()
  around lines 855-859:
  const wrappedFunction = withAgentContext(
    this[methodName as keyof this] as (...args: any[]) => any
  ) as any;
  4. Replaces Method on Prototype: It then replaces the method on the constructor's
  prototype:
  this.constructor.prototype[methodName as keyof this] = wrappedFunction;
  5. The Critical Problem: The withAgentContext function calls getCurrentAgent() at
  line 275, which in turn calls agentContext.run() at lines 276-277. When the wrapped
  <redacted> is called, it:
    - Calls getCurrentAgent() (line 275)
    - Executes agentContext.run() which calls method.apply(this, args) (line 277)
    - But now this[methodName] points to the wrapped version (due to the prototype
  replacement)
    - This creates an infinite recursion: wrapped function → getCurrentAgent() →
  agentContext.run() → wrapped function again

  The Problem with <redacted> Specifically

  Your <redacted> method calls this.<redacted2>, and
   when <redacted> gets auto-wrapped, any internal method calls within the
  agent context trigger the infinite loop.

  Solution Plan
  ⎿  User rejected Claude's plan:
     ╭───────────────────────────────────────────────────────────────────────────────────╮
     │ Fix Infinite Loop in Agents Library Auto-wrap Function                            │
     │                                                                                   │
     │ Root Cause                                                                        │
     │                                                                                   │
     │ The _autoWrapCustomMethods() function in the agents library creates infinite      │
     │ recursion when wrapping @callable() methods. It replaces the original method on   │
     │ the prototype with a wrapped version, but the wrapped function calls itself       │
     │ recursively.                                                                      │
     │                                                                                   │
     │ Solution Options                                                                  │
     │                                                                                   │
     │ Option 1: Quick Fix - Skip Already Wrapped Methods (Recommended)                  │
     │                                                                                   │
     │ - Add a check in _autoWrapCustomMethods() to detect and skip methods that are     │
     │ already wrapped                                                                   │
     │ - Add a unique property or symbol to wrapped functions to identify them           │
     │ - This prevents double-wrapping and infinite loops                                │
     │                                                                                   │
     │ Option 2: Store Original Methods                                                  │
     │                                                                                   │
     │ - Modify the autowrap logic to store original methods separately before wrapping  │
     │ - Ensure wrapped functions call the stored original method instead of             │
     │ this[methodName]                                                                  │
     │                                                                                   │
     │ Option 3: Exclude Problematic Methods                                             │
     │                                                                                   │
     │ - Add logic to exclude specific methods from auto-wrapping that are known to      │
     │ cause issues                                                                      │
     │ - Less ideal as it's method-specific rather than fixing the root cause            │
     │                                                                                   │
     │ Implementation Steps                                                              │
     │                                                                                   │
     │ 1. Modify _autoWrapCustomMethods() in                                             │
     │ /Users/.../agents/packages/agents/src/index.ts around line 821     │
     │ 2. Add wrapped function detection logic before line 855                           │
     │ 3. Test with the <redacted> method to ensure the infinite loop is         │
     │ resolved                                                                          │
     │ 4. Verify other @callable() methods still work correctly                          │
     │                                                                                   │
     │ This fix will resolve the "Maximum call stack size exceeded" error while          │
     │ preserving the intended functionality of the agents library.                      │
     ╰───────────────────────────────────────────────────────────────────────────────────╯

> why doesn't it always happen? it seems to cause problems maybe 1 in 100 times. can you
   explain why?

⏺ Great question! The reason this infinite loop doesn't happen consistently (only ~1%
  of the time) is likely due to timing and execution context dependencies. Let me
  explain the probable causes:

  Why It's Intermittent

  1. Agent Context State

  The getCurrentAgent() call at line 275 depends on agentContext.getStore() having a
  valid store. If the agent context isn't properly set up when
  _autoWrapCustomMethods() runs, getCurrentAgent() returns undefined values:

  // From getCurrentAgent() implementation
  if (!store) {
    return {
      agent: undefined,
      connection: undefined,
      request: undefined,
      email: undefined
    };
  }

  When this happens, the withAgentContext wrapper doesn't enter the problematic
  agentContext.run() call, avoiding the infinite loop.

  2. Async Constructor Timing

  Your <redacted3> constructor calls _autoWrapCustomMethods() synchronously,
   but the agent context might not be fully established yet. The context is typically
  set up during request handling, so:

  - Most of the time: Constructor runs before any request context → no infinite loop
  - Rare cases: Constructor runs during/after request handling → context exists →
  infinite loop

  3. Method Call Timing

  The infinite loop specifically happens when:
  1. _autoWrapCustomMethods() wraps <redacted>
  2. Something triggers a call to <redacted>
  3. AND the agent context is active at that moment

  If <redacted> isn't called immediately, or is called when no agent context
  is active, the loop doesn't occur.

  4. Race Condition with Multiple Instances

  If multiple agent instances are created concurrently, the prototype modification at
  line 872-873:

  this.constructor.prototype[methodName as keyof this] = wrappedFunction;

  Could create timing-dependent behavior where sometimes the original method is
  called, sometimes the wrapped version.

[threepointone]

interesting catch, will investigate

[threepointone]

potential fix here: #434 wanna try with agents@beta?

[kchro3]

just to share more context, i am not using any getters or accessing any state in my callable function, so I don't think that this would help. I'm also not seeing the Uncaught Error: no such table: cf_agents_state: SQLITE_ERROR Error error that @Flouse mentioned.

[threepointone]

another take #442

(it would help if we had a repro haha)

[threepointone]

hey, are you using locationHint by any chance?

[kchro3]

#442 aligns with what claude code was saying too. i'll give it a try. i'm not using locationHint

[threepointone]

we shipped it in agents@0.1.0 (but that also requires moving to ai@5 if you're using AIChatAgent)

[whoiskatrin]

@kchro3 still experiencing the issue after the updates?

[whoiskatrin]

@kchro3 just following up on this

[whoiskatrin]

This should be fixed now by #486

[kchro3]

Thanks for the follow ups! Lgtm