Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

A manual user follow-up can remain visibly queued behind background cron/compaction work in the same agent session, making the UI look stuck even though the queue eventually drains.

Steps to reproduce

1. Run a long agent turn in a Control UI session until it enters over-context compaction.
2. While the session is compacting, submit a manual follow-up in the same visible chat.
3. Let a scheduled review-poll/cron turn target the same session before the manual follow-up is serviced.
4. Observe the Control UI showing the manual message as queued while compaction/background work continues.

Expected behavior

Manual, user-visible follow-ups for a session should be serviced before background cron/maintenance turns already waiting on that same session lane, or the UI should clearly show that the item is waiting behind background work.

Actual behavior

The manual follow-up appeared as Queued (1) while the session also showed Compacting context.... Gateway diagnostics recorded a queued message for the affected session with queueDepth=2, then an active run completed with queueDepth=1, then another run started with queueDepth=1. Later diagnostics showed the run completed with queueDepth=0, so this was transient rather than permanently stuck, but the user-facing state was misleading and allowed background work to take the visible session turn first.

OpenClaw version

NOT_ENOUGH_INFO

Operating system

NOT_ENOUGH_INFO

Install method

pnpm dev / local gateway logs

Model

NOT_ENOUGH_INFO

Provider / routing chain

NOT_ENOUGH_INFO

Additional provider/model setup details

NOT_ENOUGH_INFO

Logs, screenshots, and evidence

User-visible evidence:
- Control UI showed the manual follow-up as `Queued (1)` while the same session showed `Compacting context...`.

Redacted session trace evidence:
- The affected session recorded a user PR-review request.
- The next assistant turn failed before producing content with an over-context error.
- The session immediately recorded a compaction entry.
- The run then yielded hidden progress through `sessions_yield` with display=false.
- A scheduled review-poll/cron message arrived immediately after the review synthesis window.

Redacted gateway trace evidence:
- `message queued ... source=pi-embedded-runner queueDepth=2 sessionState=processing`
- active run completed with `queueDepth=1`
- a new run started with `queueDepth=1`
- `lane wait exceeded ... queueAhead=1`
- `lane wait exceeded ... queueAhead=0`
- later context diagnostics showed `compactionSummary:1`
- a later run completed with `queueDepth=0`

Impact and severity

Affected: Control UI users sending manual follow-ups in a session that is concurrently compacting and receiving scheduled/background turns.
Severity: Medium/High because it makes a direct user request look stuck or lost and can let background work appear to take precedence over the human follow-up.
Frequency: Observed once directly with supporting queue/lane diagnostics.
Consequence: The UI hides whether the queued item is a human message, cron message, continuation, subagent resume, or compaction, causing misleading stuck-session UX.

Additional information

The current code path used a FIFO command queue for session lanes and did not classify queued session work by source priority. A focused fix should prioritize user/manual embedded runs over cron/heartbeat/memory/overflow maintenance work when selecting the next queued item for the same session lane.