Summary

Add an immediate scripted “session busy / waiting for model” reply (with optional cancel/new-session actions) when a user sends a message to a currently locked session.

Problem to solve

When a model takes a long time to respond (e.g., 30–120+ seconds), the session is locked while the request is still running. If the user sends another message to the same session during that time, the current behavior is confusing:

• The user may receive no clear response (or only a timeout/error much later).
• Typing indicators may stop before the actual reply arrives.
• It is unclear whether the bot is:
  • waiting for a model response,
  • running tools,
  • rate-limited/retrying,
  • or actually stuck/broken.

This creates a poor UX and leads users to resend messages, open duplicate sessions, or restart services unnecessarily.

Proposed solution

Detect "session busy" (active session lock) before entering provider execution / fallback loops, and return an immediate scripted status reply via the active channel bridge (Telegram/VK/Webchat/etc.) instead of silence or delayed failure.

Desired behavior

When a new message arrives for a locked session:

1. Do not invoke the model again for that same session/message.
2. Return a fast status reply (scripted/system-generated), for example:
   • "⏳ Session is busy: previous request is still running (waiting for model response)."
3. Include next actions (configurable / channel-safe), such as:
   • /wait — do nothing, keep waiting
   • /cancel (or /stop) — cancel the running request
   • /new — start a new session
4. Keep a typing/status heartbeat active while the original request is still running (where the channel supports it).
5. (Optional but very useful) Expose a busy reason in logs and/or response text:
   • waiting_model_response
   • tool_running
   • rate_limited
   • retrying
   • queue_wait

Implementation notes (high-level)

• Raise / propagate a dedicated SessionBusyError (or equivalent) as an early path when lock acquisition fails for an active session.
• Bridge layers (Telegram/VK/Webchat) should map this error to a user-facing status message instead of generic failure handling.
• Avoid running the fallback model loop when the failure is clearly "session busy" (not a provider failure).

Backward compatibility

• Default behavior can remain unchanged unless enabled by config.
• Or enable by default with conservative scripted text and no destructive action commands.

Alternatives considered

1. Manual prompt instructions ("if busy, say X")

   • Weak because the model is not the right layer to handle session lock state reliably.
   • Fails when the model is never invoked due to lock.

2. Rely on typing indicator only

   • Insufficient because typing can stop early and does not explain why the bot is not replying yet.

3. User manually starts a new session

   • Works as a workaround but loses continuity/context and increases confusion.

4. Local custom patch in a bridge

   • Useful temporarily, but this should be standardized in core gateway/bridge behavior.

Impact

Affected users/systems/channels

• Users interacting with OpenClaw through chat bridges (especially Telegram, VK, Webchat)
• Any deployment using slower models, tool-heavy workflows, or intermittent providers

Severity

• Medium to High (UX issue that often looks like a functional failure)

Frequency

• Intermittent to frequent, depending on model latency and workload
• Common with slower models / long prompts / tool execution chains

Consequence

• Users think the bot is frozen or broken
• Duplicate messages and repeated commands
• Unnecessary /new sessions or service restarts
• Lost time during troubleshooting
• Reduced trust in the system during long-running tasks

In practice, this causes avoidable support/debug overhead and makes normal long-latency behavior indistinguishable from real failures.

Evidence/examples

• Reproducible scenario: send a request to a slower model (e.g., Kimi K2.5) that takes ~30–120s, then send another message in the same session before the first request finishes.
• Observed behavior: session lock prevents concurrent processing in the same session, but the user receives no clear "busy/waiting" explanation.
• Logs show session lock timeouts / busy behavior, while other sessions may continue to work normally (indicating a session-level UX gap rather than a full system outage).

Suggested attachments:

• Screenshot/video of chat UX during the wait (typing stops, no status)
• Filtered gateway logs showing lock-related diagnostics
• Example of expected scripted status message

Additional information

• This request is not asking to remove session locking. Session locking is valid and necessary.
• The request is to improve user-visible behavior while a lock is active.
• A clear status reply plus cancel/new-session actions would significantly reduce confusion and unnecessary retries/restarts.
• Should remain backward-compatible with existing config keys and bridge behavior.