[BUG] generateReflectionText 56-second timeout when plugin hook triggers /reset or /new for non-agent:main sessions

[jlin53882]

Bug Description

When /reset or /new is triggered via a Discord channel (e.g., dc-channel--1476858065914695741), the command:reset hook in memory-lancedb-pro calls generateReflectionText(), which internally calls resolveAgentPrimaryModelRef(params.cfg, params.agentId).

For plugin-triggered hooks, OpenClaw core passes a plugin-scoped config to the hook context. This config lacks an agents section (it only contains plugins.entries.memory-lancedb-pro.config.*). When resolveAgentPrimaryModelRef() is called with this config for a dc-channel--... agent ID, it returns undefined because cfg.agents is undefined.

This causes runEmbeddedPiAgent to receive provider=undefined, model=undefined. The Pi runner then falls back to the hard-coded default openai/gpt-5.4, which has no API key configured, resulting in a 56-second timeout before minimal fallback activates.

Steps to Reproduce

1. Have a non-agent:main agent configured (e.g., dc-channel--...)
2. Trigger /reset on a Discord channel that uses this agent
3. Observe: ~56-second delay before command completes
4. Check reflection file — it contains: (fallback) Reflection generation failed; storing minimal pointer only.

Expected Behavior

/reset completes in normal time (~5-10 seconds) with full reflection content.

Actual Behavior

• /reset takes ~56 seconds for non-agent:main agents
• Reflection degrades to minimal pointer (no actual memory content stored)
• Auto-recall also appears slow (cascading effect from the reflection bottleneck)

Root Cause

index.ts line 1157-1158:

const modelRef = resolveAgentPrimaryModelRef(params.cfg, params.agentId);
const { provider, model } = modelRef ? splitProviderModel(modelRef) : {};

When params.cfg is plugin-scoped, resolveAgentPrimaryModelRef returns undefined, causing the cascade to the 56-second timeout.

Impact

• All non-agent:main agents affected (dc-channel--..., codex, review-claw, etc.)
• Memory reflections are degraded to minimal pointers for affected agents
• Auto-recall performance degrades due to reflection bottleneck

Environment

• Plugin: memory-lancedb-pro
• OpenClaw: latest
• Trigger: command:reset or command:new via Discord channel hook
• Affected agents: all non-agent:main agents

Fix

PR #618 — add fallback to config.llm.model when resolveAgentPrimaryModelRef returns undefined.

Test Results (2026-04-14)

Scenario	Before Fix	After Fix
dc-channel /reset time	~56 seconds	~5-10 seconds
Reflection content	(fallback) minimal pointer	Full content
Auto-recall	Slow/timeout	Normal

[jlin53882]

Test Results (2026-04-14)

Before Fix

• dc-channel /reset: ~56 seconds, then degraded to (fallback) minimal pointer
• Reflection file contained: (fallback) Reflection generation failed; storing minimal pointer only.
• Auto-recall also appeared slow due to the same bottleneck

After Fix (applied locally + gateway restarted)

• dc-channel /reset: Completes in normal time (~5-10 seconds)
• Reflection file: Full content, no (fallback) marker
• Auto-recall timeout issues also disappeared

Root Cause Confirmed

The fix ensures that when resolveAgentPrimaryModelRef returns undefined (due to plugin-scoped cfg lacking agents section), it falls back to config.llm.model (MiniMax M2.1) instead of letting the Pi runner fall back to openai/gpt-5.4.

Note

There is a secondary issue with smart-extraction LLM timeouts (MiniMax-M2.1 30-second timeout). This is a separate concern related to the smart-extraction feature's LLM call timeouts, not the reflection issue. Smart-extraction has a regex fallback so it does not break functionality, but users may want to increase the llm.timeoutMs setting if MiniMax API is slow.

[jlin53882]

Additional Observation

When the fix was applied locally to the user's production environment (dc-channel--1476858065914695741), both issues resolved simultaneously:

• Before fix: dc-channel /reset caused a 56-second timeout AND auto-recall appeared slow/unresponsive
• After fix: Both the /reset reflection completion time AND auto-recall performance returned to normal

This suggests the reflection bottleneck was cascading into the auto-recall pipeline, causing the auto-recall timeout issues that were originally thought to be a separate problem.