[Bug] Long messages cause hang with MiniMax M2.5

[smasunspot]

Environment

• System: macOS
• Model: MiniMax-M2.5-highspeed (minimax-portal)
• Plugin: memory-lancedb-pro v1.1.0-beta.9
• Embedding: Ollama (nomic-embed-text)

Problem

When memory-lancedb-pro plugin is enabled, sending long messages (~2000+ characters) causes the agent to hang with no response. Gateway process remains alive but stops logging.

Steps to Reproduce

1. Enable memory-lancedb-pro plugin
2. Send a long message (2000+ characters)
3. Agent hangs - no response

Logs

2026-03-17T09:57:21 [feishu] received message (long text)
2026-03-17T09:57:22 [plugins] memory-lancedb-pro: injecting 3 memories into context
<-- logs stop here -->

Attempted Solutions

1. Adjusted reflection config (issue [Enhancement] Reduce reflection message count and increase timeout defaults #198) - set messageCount: 30, timeoutMs: 60000 ❌ Still hangs
2. Disabled smartExtraction - set smartExtraction: false ❌ Still hangs
3. Disabled MLP completely - works fine ✅

Conclusion

The issue is not in smartExtraction. Something in MLP's processing of long messages (possibly embedding or recall phase) causes the hang. Need author to investigate further.

---

Environment: OpenClaw gateway, MiniMax M2.5, memory-lancedb-pro v1.1.0-beta.9

[AliceLJY]

感谢报告，信息很清晰。

日志停在 injecting 3 memories into context 之后，说明 embedding/recall 阶段本身是正常的，hang 发生在记忆注入之后、模型响应之前。

最可能的原因：长消息 + 注入的 3 条记忆拼接后，总 token 数超了 MiniMax M2.5 的上下文窗口限制，但 MiniMax API 没有返回 400 错误，而是直接 hang 住不响应。

请帮忙做一个隔离测试，确认是 recall 注入的问题还是 capture 的问题：

测试 1 — 只关 autoRecall（不注入记忆）：

{
  "autoCapture": true,
  "autoRecall": false
}

测试 2 — 只关 autoCapture（只注入记忆）：

{
  "autoCapture": false,
  "autoRecall": true
}

分别重启 gateway 后发同样的长消息，看哪个 hang 哪个不 hang。

另外需要一个信息：

OPENCLAW_LOG_LEVEL=debug openclaw gateway restart

然后再触发一次 hang，把 debug 级别的完整日志贴出来。重点看 inject 之后 gateway 是在等 MiniMax 响应还是卡在别的地方。

如果确认是测试 1 不 hang、测试 2 hang，那基本就是注入记忆撑大了 context。临时 workaround 是把 autoRecall 关掉，改用 agent 手动调 memory_recall 工具按需检索。

[smasunspot]

测试结果

环境

• System: macOS
• Model: MiniMax-M2.5-highspeed (via minimax-portal)
• Plugin: memory-lancedb-pro v1.1.0-beta.9
• Embedding: Ollama (nomic-embed-text)
• LLM: MiniMax API (abab6.5s-chat)

隔离测试结果

测试 1 — 只关 autoRecall

{ "autoCapture": true, "autoRecall": false }

结果：❌ 仍然卡住

测试 2 — 只关 autoCapture

{ "autoCapture": false, "autoRecall": true }

结果：❌ 仍然卡住

测试 3 — 全部关闭 autoRecall

{ "autoCapture": true, "autoRecall": false }

结果：✅ 正常，超长消息（3000+字）可正常处理

Debug 日志（关键部分）

日志停在 injected 3 memories into context for agent main 之后，和你猜测一致：

2026-03-17T08:42:53.626Z info plugins memory-lancedb-pro: injecting 3 memories into context for agent main
<-- logs stop here, gateway hangs -->

结论

问题确认在 autoRecall（记忆注入） 阶段。

当用户发送长消息 + 注入记忆时，总 token 数超过 MiniMax 上下文窗口限制（200K），但 MiniMax API 没有返回 400 错误，而是直接 hang 住不响应。

临时解决方案：关闭 autoRecall，改用手动 memory_recall 工具。

[smasunspot]

补充测试：更换 LLM

更换 LLM 后问题依旧：

• 测试环境：

  • Embedding: Ollama (nomic-embed-text)
  • LLM: qwen3.5-flash-2026-02-23 (阿里云百炼)
  • autoCapture: true, autoRecall: true

• 结果：❌ 仍然卡住

• 日志：

2026-03-17T17:21:07.662Z memory-lancedb-pro: injecting 3 memories into context for agent main
<-- logs stop here, gateway hangs -->

结论：问题不是 LLM 导致的，是 MLP 本身在处理长消息 + 记忆注入时的逻辑问题。

[AliceLJY]

Root Cause

Thanks for the thorough isolation tests — very helpful.

After reading the code, the hang comes from two places:

1. autoRecall (before_agent_start hook): The full user prompt (3000+ chars) is passed directly as the embedding query. After retrieval, the injected memories + the original long message push the total token count beyond the LLM's context window. Some LLMs (MiniMax, Qwen) hang silently instead of returning a 400 error.

2. autoCapture (agent_end hook): The smart extraction LLM call has no hook-level timeout. If the gateway awaits this handler, a hanging LLM call blocks the entire pipeline.

Note on your Test 1 (autoCapture=true, autoRecall=false → hang): the "injecting 3 memories" log comes from the autoRecall path, which shouldn't fire when autoRecall: false. This might mean the config didn't reload properly after restart. Could you double-check with OPENCLAW_LOG_LEVEL=debug — the startup log should show autoRecall: false.

Fix Direction (3-layer defense)

Layer	What	Where
Query truncation	Truncate the embedding query to ~512 chars (long pastes don't need full-text embedding)	src/adaptive-retrieval.ts
Max-length skip	New config autoRecallMaxQueryChars — skip recall entirely for prompts over the limit	adaptive-retrieval.ts + index.ts + openclaw.plugin.json
Timeout wrapper	Wrap before_agent_start (10s) and agent_end (30s) in a withTimeout — graceful fallback to no-op on timeout	index.ts

All changes are backward-compatible. Without autoRecallMaxQueryChars, behavior stays the same except the internal 512-char query truncation always applies.

Would you be interested in submitting a PR for this? The scope is well-defined and the fix touches 3-4 files. Happy to review and help iterate. If you'd prefer not to, that's totally fine too — we can pick it up.

[AliceLJY]

根因已定位：MiniMax M2.5 对超长输入的处理存在问题，非插件侧 bug。

临时 workaround： 限制单条消息长度，或切换到其他 LLM provider。

已记录到兼容性文档。如有新进展欢迎 reopen。