[Enhancement] auto-recall 3000ms timeout is too aggressive and should be configurable #314
Description
Summary
memory-lancedb-pro currently hard-codes auto-recall startup timeout to 3000ms, and that default appears too aggressive for real OpenClaw deployments using remote embedding APIs.
In our environment, auto-recall does not fail consistently because retrieval is broken; instead it sometimes succeeds and sometimes times out under normal load, which means the default timeout is sitting too close to the real retrieval latency budget.
This makes long-term memory injection flaky even when the system is otherwise healthy.
Current behavior
On memory-lancedb-pro@1.1.0-beta.9, the plugin logs warnings like:
memory-lancedb-pro: auto-recall timed out after 3000ms; skipping memory injection to avoid stalling agent startup
At the same time, in adjacent runs / adjacent agents, we also see successful logs like:
memory-lancedb-pro: injecting 3 memories into context for agent qa
So this is not a simple “retrieval is down” case. It looks more like the default timeout is too tight and gets tripped by normal network jitter / gateway concurrency / retrieval variance.
Environment
- OpenClaw:
2026.3.13 - Plugin:
memory-lancedb-pro@1.1.0-beta.9 - autoRecall:
true - autoCapture:
true - smartExtraction:
false - retrieval mode:
hybrid - embedding model:
text-embedding-3-small - memory store size: ~1091 memories
Why this seems too aggressive
In the plugin source, the timeout is currently hard-coded:
const AUTO_RECALL_TIMEOUT_MS = 3_000;In our environment, even a cold manual recall path is already close to that threshold. A simple manual search took about 3369ms end-to-end on one run, which means the 3000ms startup budget is too close to the real-world latency envelope.
That creates a bad UX pattern:
- memory injection is flaky rather than predictably on/off
- startup sometimes includes useful memory context, sometimes silently skips it
- operators have no config knob to tune behavior for remote embeddings or slower networks
Expected behavior
One of these would be much safer:
- Increase the default auto-recall timeout to something like
8000ms - Make auto-recall timeout configurable in plugin config
- Ideally do both: higher default + config override
Suggested fix
Suggested direction:
- add config like
autoRecallTimeoutMs - default it to something less brittle than
3000ms(for example8000ms) - keep the current “skip injection instead of stalling forever” behavior, which is good
That would preserve startup safety while making recall more reliable for hosted / remote embedding setups.
Related issues
This feels related but not identical to:
- Heartbeat / NO_REPLY turns may still trigger autoRecall injection and cause compaction-related latency #137 Heartbeat / NO_REPLY turns may still trigger autoRecall injection and cause compaction-related latency
- Startup checks: retriever.test() frequently times out after 8000ms (OpenClaw 2026.3.2, WSL2) #60 Startup checks:
retriever.test()frequently times out after 8000ms - [Bug] retriever.test() times out on startup even with working embedding API #218
retriever.test()times out on startup even with working embedding API
Those issues point in the same direction: retrieval latency is real and environment-dependent, so hard-coded tight budgets are fragile.
Extra note
There is also a framework-level OpenClaw issue about before_agent_start hooks needing stronger timeout guardrails (openclaw/openclaw#48534), but this report is specifically about the plugin-side auto-recall timeout default being too low / not configurable.