Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Session stops processing new messages after prompt-error: aborted [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#44610•Fetched 2026-04-08 00:44:36
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
mcfnmcfn
Participants
funpigfunpigmcfnmcfn
Timeline (top)
commented ×1cross-referenced ×1subscribed ×1

After a prompt-error: aborted event is recorded in a session JSONL, the session stops processing any new inbound messages. Messages sent to the group chat are silently dropped — they never appear in the session JSONL and no reply is generated.

Error Message

After a prompt-error: aborted event is recorded in a session JSONL, the session stops processing any new inbound messages. Messages sent to the group chat are silently dropped — they never appear in the session JSONL and no reply is generated. 3. A prompt-error: aborted custom event is written as the last entry in the session JSONL After a prompt-error: aborted, the session should recover and continue processing new inbound messages normally. 2026-03-13T02:17:03.890Z type=custom openclaw:prompt-error error=aborted Gateway log shows no inbound dispatch for the group after the error, even though Telegram delivered the messages.

Root Cause

After a prompt-error: aborted event is recorded in a session JSONL, the session stops processing any new inbound messages. Messages sent to the group chat are silently dropped — they never appear in the session JSONL and no reply is generated.

Fix Action

Workaround

Sending a message to the group via the message tool (not through the session) can sometimes "unstick" the session by triggering a fresh inbound event.

PR fix notes

PR #48807: fix(health-monitor): drain active runs before abort on channel restart

Description (problem / solution / changelog)

Problem

When the channel health monitor triggers a channel restart, it immediately calls abort.abort(), which kills any in-flight agent runs. This causes a race condition where:

  • Reactions survive (they fire early on message receipt)
  • Text replies are silently dropped with aborted=true (they're mid-delivery when abort fires)

The issue manifests post-gateway-restart: the health monitor fires quickly, sees a channel briefly unhealthy during the reconnect window, and aborts active runs before they finish delivering replies.

Observed in Discord after the 2026.3.14 update: bot reacted with 👀 but sent no text replies for ~10 minutes after a gateway restart.

Fix

Three changes to src/gateway/channel-health-monitor.ts:

  1. 30s drain window — stopChannel now waits for any active agent runs to complete (up to 30s) before calling abort.abort(), preventing mid-delivery drops
  2. 60s cooldown floor — minimum 60s between health-monitor-triggered restarts, preventing rapid cycling that compounds the problem
  3. Fresh config — health evaluations now use a resolveFreshTiming callback instead of params.cfg captured at monitor startup, avoiding stale timing values after config changes

Testing

  • Added 5 new test cases to channel-health-monitor.test.ts covering: drain window wait, cooldown floor enforcement, drain timeout fallback, stale config refresh, and the reaction-survives/reply-drops scenario
  • All existing tests pass

Related

  • #44610 — session stops processing after prompt-error: aborted (related symptom, different scope)
  • #37435 — track stopped channels on restart (different: prevents restart of already-stopped channels)
  • #45712 — reconnect grace period for Discord (different: prevents excessive restarts on WS drop)

Changed files

  • src/gateway/channel-health-monitor.test.ts (modified, +349/-10)
  • src/gateway/channel-health-monitor.ts (modified, +135/-5)

Code Example

2026-03-13T01:58:26.540Z  role=assistant  (last successful reply)
2026-03-13T02:17:03.890Z  type=custom     openclaw:prompt-error  error=aborted
(no more entries — messages sent at 02:00 UTC were never recorded)
RAW_BUFFERClick to expand / collapse

Description

After a prompt-error: aborted event is recorded in a session JSONL, the session stops processing any new inbound messages. Messages sent to the group chat are silently dropped — they never appear in the session JSONL and no reply is generated.

Steps to Reproduce

  1. A group chat session is actively processing messages
  2. A model run is triggered but gets aborted (e.g., timeout, concurrent run conflict)
  3. A prompt-error: aborted custom event is written as the last entry in the session JSONL
  4. Subsequent messages from users in the group are silently dropped — no new user role messages appear in the JSONL, no assistant replies are generated

Expected Behavior

After a prompt-error: aborted, the session should recover and continue processing new inbound messages normally.

Actual Behavior

The session enters a "stuck" state. New messages are never recorded and no replies are sent. The session appears permanently broken until manually intervened.

Evidence

Session JSONL timeline:

2026-03-13T01:58:26.540Z  role=assistant  (last successful reply)
2026-03-13T02:17:03.890Z  type=custom     openclaw:prompt-error  error=aborted
(no more entries — messages sent at 02:00 UTC were never recorded)

Gateway log shows no inbound dispatch for the group after the error, even though Telegram delivered the messages.

Environment

  • OpenClaw version: 2026.3.7 (build 42a1394)
  • Model: amazon-bedrock/us.anthropic.claude-opus-4-6-v1
  • Channel: Telegram group chat
  • Node.js: v24.13.0
  • OS: macOS (Darwin 25.1.0 arm64)

Workaround

Sending a message to the group via the message tool (not through the session) can sometimes "unstick" the session by triggering a fresh inbound event.

extent analysis

Fix Plan

To resolve the issue, we need to modify the session processing logic to recover from the prompt-error: aborted event. Here are the steps:

  • Modify the processMessage function to check for the prompt-error: aborted event and reset the session state if encountered.
  • Add a retry mechanism to handle aborted model runs and prevent the session from getting stuck.

Example code snippet:

// processMessage function
if (message.type === 'custom' && message.error === 'aborted') {
  // Reset session state
  session.state = 'idle';
  // Retry the model run or trigger a new inbound event
  triggerNewInboundEvent();
}

// triggerNewInboundEvent function
function triggerNewInboundEvent() {
  // Send a new message to the group to trigger a fresh inbound event
  const newMessage = { role: 'user', text: ' ' };
  dispatchMessage(newMessage);
}

Verification

To verify the fix, follow these steps:

  • Reproduce the issue by triggering a prompt-error: aborted event in a session.
  • Send new messages to the group and check if they are recorded in the session JSONL and if assistant replies are generated.
  • Verify that the session recovers from the aborted event and continues processing new inbound messages normally.

Extra Tips

  • Make sure to test the fix thoroughly to ensure it works as expected in different scenarios.
  • Consider adding logging and monitoring to detect and handle similar issues in the future.
  • Review the OpenClaw documentation and GitHub issues to see if similar problems have been reported and if there are any known workarounds or fixes.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#embedding generation#cache error#pipeline error#runtime error#dependency conflict

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING