Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Scheduled cron review work and human web-chat turns can share the same main-session lane, causing interactive replies to wait behind background cron work.

Steps to reproduce

1. Configure a recurring scheduled job that targets the default agent main session with sessionTarget="main" and wakeMode="now".
2. Let the scheduled job start a long heartbeat/model turn on the default agent's main web-chat session.
3. While that cron-triggered turn is still active, send a short human web-chat message to the same agent.
4. Observe the human turn enter a session that is already marked processing instead of running independently.

Expected behavior

Background cron work should run on a cron-owned non-interactive lane, while human web-chat messages to the same agent remain on the human main-session lane. Cron output can still use the main session's last delivery context when it needs to reply, but routine cron turns should not hold or confuse the human chat lane.

Actual behavior

Gateway logs showed a cron-triggered main-session run lasting about 66 seconds. A human web-chat message was queued for the same redacted session while the cron run was still active, then started with prev=processing new=processing reason="run_started" queueDepth=1. The affected human PR follow-up took 37.6 seconds, and two later tiny web-chat replies took 12.6 seconds and 15.1 seconds.

OpenClaw version

2026.5.17

Operating system

NOT_ENOUGH_INFO

Install method

pnpm dev / gateway dev logs

Model

NOT_ENOUGH_INFO

Provider / routing chain

NOT_ENOUGH_INFO

Additional provider/model setup details

NOT_ENOUGH_INFO

Logs, screenshots, and evidence

Redacted trace summary:
- A cron-nested task ran for 488261ms while heartbeats reported active=1 waiting=0 queued=0 for many minutes.
- A cron-triggered main-session run started at 19:20:04 UTC and completed at 19:21:08 UTC after 66592ms/66608ms.
- A human web-chat message was queued at 19:21:03 UTC for the same redacted session key while the cron run was still active.
- The human run started with prev=processing new=processing reason="run_started" queueDepth=1.
- That human follow-up completed with duration=37608ms.
- Another cron main-session run at 19:40 UTC completed after about 63990ms.
- A later human "u there?" web-chat turn took 12581ms end-to-end for a tiny answer.
- The next human "why are you so slow?" web-chat turn took 15148ms end-to-end for a tiny answer.
- A later cron main-session run lasted about 65973ms/65975ms, showing the pattern repeated.
- A liveness warning during a slow human reply showed active and queued work on the same redacted main-session lane, with eventLoopDelayP99Ms=584.1 and eventLoopDelayMaxMs=2910.8.

Impact and severity

Affected: users interacting with web chat while scheduled review/cron work targets the same agent main session.
Severity: High, because background automation can delay or confuse interactive human replies.
Frequency: observed repeatedly in the captured log window.
Consequence: short human messages can take 12-37 seconds and enter a session state already marked processing by cron work.

Additional information

A narrow code-path review found current main-session cron jobs enqueue their system event and heartbeat wake using the job's main sessionKey. That lets scheduled work target the same durable lane used by human web chat.