#Update issues

1 messages · Page 1 of 1 (latest)

umbral drift
#

I've just updated to 2026.5.12 and noticed that when I issue /stop from telegram, it no longer stops the prompt, it just seems to ignore it

dense totemBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

midnight patioBOT
#

That sounds like a regression, not expected behavior. I checked the 2026.5.12 code path and Telegram /stop is still supposed to be registered as a native command and abort the active run.

One likely failure mode: Telegram native /stop is going through the slash-command wrapper path but not targeting the active Telegram conversation/run correctly, so it appears ignored.

Quick workaround to try: send stop without the slash in the same Telegram chat while the run is active. In groups, if your bot only reacts when mentioned, try mentioning it with stop instead of using /stop.

For debugging, please grab the log lines around the failed /stop:

openclaw --version
openclaw logs --follow

Then trigger a long prompt and send /stop from Telegram. If there’s no abort/cancel line, this is probably worth filing as a bug: https://github.com/openclaw/openclaw/issues

Docs for the general diagnostic commands: https://docs.openclaw.ai/help/faq

umbral drift
#

Are these errors related

23:00:07
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-default
23:00:07
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-lead-scout
23:00:07
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-portfolio-guardian
23:00:07
error
channels/telegram
[telegram][diag] isolated polling ingress started spool=/home/admin/.openclaw/telegram/ingress-spool-sql

midnight patioBOT
#

Probably not directly. Those specific lines are badly-labelled diagnostics, not necessarily failures:

[telegram][diag] isolated polling ingress started spool=...

In 2026.5.12 Telegram polling runs through an isolated ingress worker and spools updates under ~/.openclaw/telegram/ingress-spool-*. Seeing one “started” line per Telegram account (default, lead-scout, etc.) just means those polling workers started.

What would be concerning is nearby lines like:

[telegram][diag] isolated polling ingress stopped outcome=error ...
[telegram][diag] isolated polling spool drain failed ...
[telegram][diag] polling cycle error ...

If normal Telegram messages still reach OpenClaw but only /stop doesn’t abort, I’d treat it as a /stop/native-command targeting bug, not the spool startup line.

If Telegram messages are intermittently not received at all, then yes, the isolated polling ingress/spool path becomes relevant. In that case, please paste ~30 lines before/after the failed /stop, especially any isolated polling ingress stopped lines.

umbral drift
#

How about these

23:01:23
warn
diagnostic
liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=37s eventLoopDelayP99Ms=14134.8 eventLoopDelayMaxMs=14134.8 eventLoopUtilization=0.995 cpuCoreRatio=1.036 active=1 waiting=0 queued=2 phase=channels.telegram.start-account recentPhases=sidecars.main-session-recovery:6ms,sidecars.restart-sentinel:98ms,post-attach.update-sentinel:77ms,sidecars.session-locks:1103ms,post-ready.maintenance:11ms,sidecars.model-prewarm:2703ms work=[active=agent:lead-scout:telegram:direct:6938637819(processing,q=2,age=16s) queued=agent:lead-scout:telegram:direct:6938637819(processing,q=2,age=16s)]
23:01:23
warn
fetch-timeout
fetch timeout reached; aborting operation
23:01:23
warn
diagnostic
liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=37s eventLoopDelayP99Ms=14134.8 eventLoopDelayMaxMs=14134.8 eventLoopUtilization=0.995 cpuCoreRatio=1.036 active=1 waiting=0 queued=2 phase=channels.telegram.start-account recentPhases=sidecars.main-session-recovery:6ms,sidecars.restart-sentinel:98ms,post-attach.update-sentinel:77ms,sidecars.session-locks:1103ms,post-ready.maintenance:11ms,sidecars.model-prewarm:2703ms work=[active=agent:lead-scout:telegram:direct:6938637819(processing,q=2,age=16s) queued=agent:lead-scout:telegram:direct:6938637819(processing,q=2,age=16s)]
23:01:23
warn
fetch-timeout
fetch timeout reached; aborting operation
23:01:26
warn
agent/embedded
[trace:embedded-run] prep stages: runId=73e075d7-8681-4221-85cf-361e17e53cf1 sessionId=630e1817-5fbf-46d0-bd8e-aadcaa6c0f3c phase=stream-ready totalMs=21492 stages=workspace-sandbox:3ms@3ms,skills:0ms@3ms,core-plugin-tools:390ms@393ms,bootstrap-context:59ms@452ms,bundle-tools:19660ms@20112ms,system-prompt:1200ms@21312ms,session-resource-loader:77ms@21389ms,agent-session:7ms@21396ms,stream-setup:96ms@21492ms

midnight patioBOT
#

Yes — these are much more likely related.

The key bit is:

eventLoopDelayP99Ms=14134.8
eventLoopUtilization=0.995
cpuCoreRatio=1.036
active=1 waiting=0 queued=2
work=[active=agent:lead-scout:telegram:direct:... queued=agent:lead-scout:telegram:direct:...]

That means the gateway’s Node event loop was basically pegged for ~14 seconds, with work queued for the same Telegram session. If /stop arrives during that, it may not be handled promptly — or it can sit behind the active/queued work, which makes it look ignored.

This line is also suspicious:

# 
bundle-tools:19660ms

Tool bundling/prep took ~20s before the run even reached stream-ready. So this looks less like “Telegram didn’t receive /stop” and more like “the gateway was overloaded/starved while starting the run, so cancellation couldn’t cut through.”

The fetch timeout reached warnings are probably fallout from the same stall/CPU saturation, or a network request getting starved/timed out while the event loop was unhealthy.

I’d file this as a 2026.5.12 regression with exactly this log block. Include:

openclaw --version
openclaw status --all

and mention that /stop from Telegram fails while liveness reports event_loop_delay, event_loop_utilization, cpu, and bundle-tools:19660ms.