Bug Description
When multiple messages are sent rapidly in succession (e.g., via Feishu), messages arriving while the session is busy get queued. When the session processes them sequentially, the replies appear to merge content from multiple queued messages together.
Steps to Reproduce
- Send message A via Feishu direct message
- While agent is processing A, immediately send message B
- Agent replies to A but the reply contains content from both A and B
- Message C may also get similarly merged
Expected Behavior
Each message should be processed and replied to independently. A reply to message A should only address content from message A, not content from queued messages B, C, etc.
Evidence
From gateway logs:
- Message A: 10:38:47, dispatch to agent:main:main
- Message B: 10:39:21 (while A still processing), dispatch to agent:main:main
- Message C: 10:56:02, dispatch to agent:main:main
- All dispatch to same session key (agent:main:main)
- Each dispatch shows "dispatch complete (queuedFinal=true, replies=1)"
- But replies contain content from multiple messages
Environment
- OpenClaw v2026.5.2
- Feishu channel
- Session: agent:main:main
Analysis
This started after upgrading to v2026.5.2. Before the upgrade (v4.x), this did not happen. PR #76485 changed queueEmbeddedPiMessage to accept messages during preflight_compacting/memory_flushing instead of rejecting them. However, this may have exposed a different bug: when the session processes queued messages sequentially, the transcript/context of previously queued messages may be bleeding into the prompt of messages being processed later.
The issue is likely in how the session transcript is constructed when processing a queued message — the queued message inherits context from the previous messages still in the queue.
Bug Description
When multiple messages are sent rapidly in succession (e.g., via Feishu), messages arriving while the session is busy get queued. When the session processes them sequentially, the replies appear to merge content from multiple queued messages together.
Steps to Reproduce
Expected Behavior
Each message should be processed and replied to independently. A reply to message A should only address content from message A, not content from queued messages B, C, etc.
Evidence
From gateway logs:
Environment
Analysis
This started after upgrading to v2026.5.2. Before the upgrade (v4.x), this did not happen. PR #76485 changed queueEmbeddedPiMessage to accept messages during preflight_compacting/memory_flushing instead of rejecting them. However, this may have exposed a different bug: when the session processes queued messages sequentially, the transcript/context of previously queued messages may be bleeding into the prompt of messages being processed later.
The issue is likely in how the session transcript is constructed when processing a queued message — the queued message inherits context from the previous messages still in the queue.