#WhatsApp 428 exit causing repeated agent:main:main session re-init on cold startScenario

1 messages · Page 1 of 1 (latest)

lime sphinx
#

Cold start after host shutdown (laptop off overnight). Cron had 5 missed jobs.
Observed sequence:
04:39:10 — webhook registered (normal startup)
04:41:11 — WhatsApp provider starting; cron running 5 missed jobs
04:41:35 — WhatsApp 428 exit → auto-restart 1/10
04:41:59 — webhook re-registered (unexpected)
04:42:41 — webhook re-registered again
04:43:10 — webhook re-registered again
04:43:36 — webhook re-registered again
04:47:05 — webhook re-registered again (during WA 408 retry loop)
Total: 1 expected + 5 unexpected re-registrations of the same webhook on agent:main:main
Per Krill's earlier confirmation: WhatsApp 428 should NOT restart agent:main:main. Only 440/logout-style states are terminal.
Question: Is the main session object being recreated on each WA reconnect attempt, or is something else queuing repeated session-init events? Could the 5 missed cron jobs firing simultaneously be contributing?
Version: 2026.4.26 | WSL2 | Docker

muted remnantBOT
#

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

quartz fableBOT
#

I checked the current source/docs path. Your earlier read is right: WhatsApp 428 should not recreate agent:main:main. In the WhatsApp reconnect path, only logged-out and 440 conflict are treated as terminal; 428/408 fall into retry/reconnect behavior.

The important distinction: if the log line is like:

[webhooks] registered route ... for session agent:main:main

that comes from the webhooks plugin registration path, not from normal session creation. So repeated “webhook registered” lines suggest plugin/route registration is being re-run or the gateway/plugin scope is being reloaded — not necessarily that the main session object is being recreated.

Cron could be contributing indirectly. Startup catch-up defaults to up to 5 missed jobs immediately, which matches your “5 unexpected” count suspiciously well. But source-wise those missed jobs should create cron/system-event/heartbeat pressure, not re-register webhook routes by themselves. So I’d look for one of these before each re-registration:

  • config change detected; evaluating reload
  • config hot reload applied
  • restarting whatsapp channel
  • gateway process/PID restart
  • plugin bootstrap/load lines
  • session reset / compaction lifecycle lines
#

My best read: not “WA reconnect recreates main session” directly; more likely cold-start cron catch-up + WA reconnect events are causing repeated runtime reload/session-init side effects, and the webhook plugin is being registered again as a consequence.

For isolation, try one cold start with cron paused/disabled, or with the 5 missed jobs removed/marked run, and see if the extra webhook registrations disappear. If yes, this is very GitHub-issue-worthy with that exact 04:39–04:48 log slice.

Docs refs:
https://docs.openclaw.ai/channels/whatsapp
https://docs.openclaw.ai/automation/cron-jobs
Issue tracker: https://github.com/openclaw/openclaw/issues

lime sphinx
#

Scenario: Cold start after host shutdown. Cron had 5 missed jobs, staggered by runtime.
Exact sequence:
04:39:10 — webhook registered (normal startup)
04:41:11 — cron: staggering missed jobs / running missed jobs after restart (count=5)
04:41:35 — WhatsApp 428 exit
04:41:59 — webhook re-registered #2
04:42:41 — webhook re-registered #3 ← no trigger visible
04:43:10 — webhook re-registered #4 ← no trigger visible
04:43:36 — webhook re-registered #5 ← no trigger visible
04:44:20 — Telegram polling stall detected
04:45:06 — cron stale delivery skipped
04:47:05 — webhook re-registered #6
Key observation: Re-registrations #3/4/5 have no config reload, session reset, plugin bootstrap, or channel restart lines between them. The webhook registration itself may be triggering the next re-registration.
Question: Is there a known feedback path where webhook plugin registration causes a session-init side effect that re-triggers registration? Could missed cron job catch-up be the root initiator?
Version: 2026.4.26 | WSL2 | Docker | 5 missed cron jobs on cold start

quartz fableBOT
#

I’d rule out the “webhook registration recursively triggers itself” theory.

In the source path I checked, [webhooks] registered route ... for session agent:main:main happens only when the webhooks plugin register() runs. Its bindSession({ sessionKey }) call just creates a bound TaskFlow helper; it does not create/reset agent:main:main or emit session-init by itself.

So repeated lines mean: something is re-loading/re-activating the plugin registry, not the webhook route causing the next registration.

The suspicious root initiator is still cron catch-up: 5 missed jobs → 5 extra registrations is too clean to ignore. My guess is:

cold start → cron catch-up starts several agent/tool/heartbeat paths → plugin registry gets loaded/reloaded repeatedly under gateway-bindable/default runtime paths → webhooks plugin register logs each time

That would also explain why there’s no visible config reload/channel restart between #3/#4/#5.

Two useful next checks:

  1. Reproduce once with cron paused: