bug: memory consolidation can take long or even fail

[Rose22]

especially when using local models. i've been using a cloud model (GLM-4.7) for a while and it's basically become impossible for my local model to consolidate the memory, it keeps failing, and i cant start a new session.

at the very least make it possible to start a new session without forcing memory consolidation? because the way it is now, it just completely breaks when it cant consolidate

also consider adding a timeout to it

[SrTopete]

What I'm getting is

2026-02-27 08:12:35.250 | INFO | nanobot.agent.loop:_consolidate_memory:431 - Memory consolidation started: 78 total, 8 new to consolidate, 25 keep
2026-02-27 08:13:16.202 | ERROR | nanobot.agent.loop:_consolidate_memory:487 - Memory consolidation failed: data must be str, not dict

And this is my config.json

{
"agents": {
"defaults": {
"model": "openai/qwen2.5:14b",
"maxTokens": 8192,
"temperature": 0.7,
"maxToolIterations": 20,
"memoryWindow": 50
}
},
"channels": {
"telegram": {
"enabled": true,
"token": "REDACTED",
"allowFrom": ["REDACTED"],
"proxy": null
}
},
"providers": {
"openai": {
"apiKey": "ollama",
"apiBase": "http://localhost:11434/v1",
"extraHeaders": null
}
},
"gateway": {
"host": "0.0.0.0",
"port": 18790
},
"tools": {
"exec": {
"timeout": 60
},
"restrictToWorkspace": false,
"mcpServers": {}
}
}

[TTdogCC]

Adding root cause analysis based on code review of loop.py:

The core problem is in _consolidate_memory — when the LLM call fails or times out, session.last_consolidated is never updated. Since consolidation is fired via asyncio.create_task() with no lock, the next message triggers another consolidation attempt on an even larger batch. This is how you get the 76 → 240 message progression in a single session.

Relevant code (loop.py ~363-444):

• last_consolidated is only updated on success (lines 441-443)
• No guard prevents multiple concurrent consolidation tasks
• Trigger condition len(session.messages) > self.memory_window keeps firing every message once exceeded

With local models (GLM4.7-flash via Ollama) this is especially bad because:

1. Ollama is single-threaded per request
2. A large consolidation call blocks the model
3. Meanwhile the main agent loop also needs the model → timeout
4. Consolidation fails → last_consolidated not updated → batch grows → repeat

Suggested fixes:

1. Update last_consolidated even on failure (to current position) so it doesn't retry the same messages
2. Add a per-session lock/flag to prevent concurrent consolidation tasks
3. Lower the trigger threshold or add a dedicated smaller model for consolidation

[Wangshixiong]

I encountered this issue recently. Here's what happened:

Timeline from logs:

21:31:51 - /new command triggered memory consolidation (250 messages)
21:31:51 ~ 21:43:56 - Agent loop blocked for ~12 minutes
21:32:49 - New message arrived: feishu received → added reaction → queued
21:37:48 - Another message arrived: same behavior
21:43:56.379 - Consolidation completed ("Memory consolidation done for 250 messages")
21:43:56.380 - Queued messages finally processed

Key observations:

1. Blocking behavior: During consolidation (~12 min), the entire agent loop was blocked. New messages were received (reactions added) but not processed until consolidation finished.

2. No feedback to user: From user perspective, the bot seemed to ignore messages for 12 minutes. No indication that consolidation was in progress.

3. Root cause in code: archive_unconsolidated() called by /new is synchronous and blocks agent/loop.py's _process_message().

Suggestions:

1. Make consolidation a background task that doesn't block message processing
2. Add a timeout for consolidation
3. Show a progress indicator or at least log "consolidation in progress" before blocking
4. Allow /new to skip consolidation with a flag like /new --skip-memory