Feishu /compact can be starved behind long model calls and evicted by the 300s per-chat cap, making large sessions unrecoverable

Summary

In OpenClaw 2026.6.1, a Feishu DM session with a large active transcript can become practically unrecoverable: user-sent /compact commands are received by the Feishu channel, but they are dispatched through the same per-chat/session lane as normal model calls. If an earlier large-context model call is still running, /compact queues behind it and can be evicted by the Feishu 300s per-chat task cap before compaction ever starts.

This creates a self-reinforcing failure loop:

1. Large session context makes normal model calls very slow.
2. Slow model calls occupy the Feishu per-chat/session lane for several minutes.
3. The user sends /compact to recover the session.
4. /compact queues behind the active model call instead of preempting it or running as maintenance work.
5. The 300s per-chat cap evicts queued work.
6. Compaction never runs, so the context remains huge and the session stays slow/unusable.

The result is that the channel can receive messages, but the user cannot recover the session from the channel itself.

Environment

• OpenClaw: 2026.6.1 (OpenClaw 2026.6.1 (2e08f0f))
• Channel: Feishu DM
• Feishu session model: xiaomi-coding/mimo-v2.5-pro
• Session size before failure: about 458k / 1049k tokens (44%)
• Compaction config:
  • agents.defaults.compaction.mode = "safeguard"
  • agents.defaults.compaction.reserveTokensFloor = 30000
  • agents.defaults.compaction.notifyUser = true

Related issues / PRs found before filing

Searches found several related but not identical reports:

• #90185 - [Core bug] /compact reply silently dropped (replies=0) on all channels in 2026.6.1
• #79409 - Bug: Feishu channel does not handle text slash commands (/compact, /new, /stop)
• #87468 - Feishu: Agent-generated replies silently dropped (replies=0, queuedFinal=false) after WebSocket reconnect
• #90240 - Session embedded-run counter stays pinned ... subsequent Slack DM inbound silently queued ...
• #90974 - broader product stability feedback with related logs

This issue is specifically about /compact being unable to recover a large Feishu session because it is queued behind normal work and subject to the same 300s per-chat eviction behavior.

Reproduction scenario

1. Use a Feishu DM session with a large transcript/context.
2. Let a normal message trigger a long-running model call.
3. While the model call is still active, send /compact in the Feishu DM.
4. Observe that Feishu receives /compact and dispatches it to the same agent/session lane.
5. Observe the session remains blocked behind the active model call.
6. Observe the 300s per-chat cap evicts queued same-key work before /compact can run.

Log evidence

The following logs are from the affected OpenClaw 2026.6.1 deployment.

/compact is received and dispatched, but the session is already blocked by long-running model work

2026-06-09T09:56:02.220+08:00 [diagnostic] long-running session: sessionId=79861423-0cb6-4369-aa0f-eafa100d8cca sessionKey=agent:main:feishu:direct:ou_b21751e6f615d213220a7290f8157fce state=processing age=283s queueDepth=1 reason=queued_behind_active_work classification=long_running activeWorkKind=model_call lastProgress=model_call:stream_progress lastProgressAge=0s recovery=none
2026-06-09T09:56:15.249+08:00 [feishu] feishu[default]: per-chat task exceeded 300000ms cap (key=feishu:default:oc_a42fa6f96e0764ec3c976fbb69ebb586); evicting from queue so later same-key messages can proceed (#70133)
2026-06-09T09:56:16.310+08:00 [feishu] feishu[default]: received message from ou_b21751e6f615d213220a7290f8157fce in oc_a42fa6f96e0764ec3c976fbb69ebb586 (p2p)
2026-06-09T09:56:16.314+08:00 [feishu] feishu[default]: Feishu[default] DM from ou_b21751e6f615d213220a7290f8157fce: /compact
2026-06-09T09:56:16.345+08:00 [feishu] feishu[default]: dispatching to agent (session=agent:main:feishu:direct:ou_b21751e6f615d213220a7290f8157fce)

/compact remains behind active model work

2026-06-09T09:57:32.220+08:00 [diagnostic] liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=39.7 eventLoopDelayMaxMs=1133.5 eventLoopUtilization=0.384 cpuCoreRatio=0.391 active=2 waiting=0 queued=2 work=[active=agent:main:feishu:direct:ou_b21751e6f615d213220a7290f8157fce(processing/model_call,q=2,age=76s last=model_call:stream_progress)|agent:main:main(processing/model_call,q=1,age=12s last=model_call:stream_progress) queued=agent:main:feishu:direct:ou_b21751e6f615d213220a7290f8157fce(processing/model_call,q=2,age=76s last=model_call:stream_progress)]

Earlier user messages produced no visible reply while the lane was unhealthy

2026-06-09T09:40:56.477+08:00 [feishu] feishu[default]: sent no-visible-reply fallback (dispatch-complete-no-visible-reply)
2026-06-09T09:40:56.478+08:00 [feishu] feishu[default]: dispatch complete (queuedFinal=false, replies=0)
2026-06-09T09:40:57.716+08:00 [feishu] feishu[default]: sent no-visible-reply fallback (dispatch-complete-no-visible-reply)
2026-06-09T09:40:57.717+08:00 [feishu] feishu[default]: dispatch complete (queuedFinal=false, replies=0)
2026-06-09T09:40:58.936+08:00 [feishu] feishu[default]: sent no-visible-reply fallback (dispatch-complete-no-visible-reply)
2026-06-09T09:40:58.937+08:00 [feishu] feishu[default]: dispatch complete (queuedFinal=false, replies=0)

Event loop delay became severe during the failure window

2026-06-09T09:51:01.020+08:00 [diagnostic] liveness warning: reasons=event_loop_delay interval=35s eventLoopDelayP99Ms=1079 eventLoopDelayMaxMs=9235.9 eventLoopUtilization=0.543 cpuCoreRatio=0.56 active=2 waiting=0 queued=0 work=[active=agent:main:feishu:direct:ou_b21751e6f615d213220a7290f8157fce(processing/embedded_run,q=0,age=0s last=model_call:ended)|agent:main:main(processing/embedded_run,q=1,age=11s last=tool:exec:ended)]

Feishu dedup persistent state is also failing in this release

This may not be the primary cause of /compact starvation, but it worsens channel recovery semantics and message handling during the incident.

2026-06-09T09:56:15.251+08:00 [feishu] feishu-dedup: legacy state import failed: Error: openKeyedStore is only available for trusted plugins in this release.
2026-06-09T09:56:15.252+08:00 [feishu] feishu-dedup: persistent state error, falling back to memory: Error: openKeyedStore is only available for trusted plugins in this release.

Expected behavior

A user-initiated maintenance/recovery command such as /compact should remain usable even when the active chat session is slow or unhealthy.

Possible acceptable behaviors:

• /compact preempts or cancels the current same-session model call, then runs compaction.
• /compact runs on a priority maintenance lane independent of normal model calls.
• The Feishu per-chat 300s cap does not evict slash-command maintenance work such as /compact, /stop, /reset, etc.
• The channel detects /compact before normal agent dispatch and invokes session compaction directly.
• A CLI/API command exists to compact a specific session without going through the channel dispatch path.

Actual behavior

/compact is received by Feishu and dispatched to the agent, but it uses the same session/per-chat lane as ordinary model work. When a large-context model call is already active, /compact queues behind it and can be evicted by the 300s cap before compaction starts. The user cannot recover the session from Feishu.

Impact

This is a serious availability issue. Once a Feishu session gets large enough to make model calls slower than the channel/task cap, the built-in recovery command (/compact) cannot execute. The session becomes effectively unusable from the user's primary messaging surface.

Suggested fixes

I think at least one of these should be implemented:

1. Parse and execute maintenance slash commands before normal agent dispatch

   • Feishu should recognize /compact as a control command and route it to session maintenance directly.
   • It should not require a normal model call to interpret or execute compaction.

2. Give /compact a priority or out-of-band maintenance lane

   • Recovery commands should not queue behind long model calls they are meant to fix.

3. Make the 300s per-chat cap command-aware

   • Do not evict queued /compact, /stop, /reset, or similar maintenance commands as ordinary chat messages.
   • Alternatively, if eviction is necessary, preserve the newest recovery command and cancel/drop older normal work instead.

4. Provide a supported CLI/API escape hatch

   • For example: openclaw sessions compact <sessionKey> or a documented gateway API.
   • In this incident, openclaw session compact ... was attempted but the CLI reported Unknown command: openclaw session.

5. Improve observability

   • Log whether a received /compact starts compaction, is queued, is evicted, or is dropped.
   • Current logs show received/dispatch but do not clearly show the lifecycle of the compact request.

Notes

This is distinct from automatic compaction threshold behavior. In this incident, the user manually sent /compact multiple times. The problem is that manual compaction cannot reliably run because it is routed through the same congested channel/session execution path.