openclaw - ✅(Solved) Fix [Bug]: Isolated cron watchdog still kills beta.4 runs at attempt_dispatch after 60s [1 pull requests, 2 comments, 3 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#81368Fetched 2026-05-14 03:32:55
View on GitHub
Comments
2
Participants
3
Timeline
5
Reactions
2
Timeline (top)
cross-referenced ×3commented ×2

This still reproduces on the latest release currently listed for users: v2026.5.12-beta.4 / OpenClaw 2026.5.12-beta.4 (d124625).

Related closed issue: #80888. I tried to reopen #80888 after posting the beta.4 evidence, but GitHub returned does not have the correct permissions to execute ReopenIssue, so I am opening this follow-up instead.

v2026.5.12-beta.4 appears to include the broader execution-milestone fix, but the packaged isCronAgentExecutionStarted() still does not treat attempt_dispatch as execution-started. In this environment, an isolated cron run can sit at attempt_dispatch past 60s and is killed by the pre-execution watchdog.

Error Message

"status": "error", "error": "cron: isolated agent run stalled before execution start (last phase: attempt-dispatch)", Longer isolated cron jobs can still be killed around 60s with a false attempt-dispatch stall error, even though the run is progressing and the configured job timeout is much longer.

Root Cause

This still reproduces on the latest release currently listed for users: v2026.5.12-beta.4 / OpenClaw 2026.5.12-beta.4 (d124625).

Related closed issue: #80888. I tried to reopen #80888 after posting the beta.4 evidence, but GitHub returned does not have the correct permissions to execute ReopenIssue, so I am opening this follow-up instead.

v2026.5.12-beta.4 appears to include the broader execution-milestone fix, but the packaged isCronAgentExecutionStarted() still does not treat attempt_dispatch as execution-started. In this environment, an isolated cron run can sit at attempt_dispatch past 60s and is killed by the pre-execution watchdog.

Fix Action

Fix / Workaround

v2026.5.12-beta.4 appears to include the broader execution-milestone fix, but the packaged isCronAgentExecutionStarted() still does not treat attempt_dispatch as execution-started. In this environment, an isolated cron run can sit at attempt_dispatch past 60s and is killed by the pre-execution watchdog.

Actual on beta.4 before local patch

{
  "status": "error",
  "error": "cron: isolated agent run stalled before execution start (last phase: attempt-dispatch)",
  "durationMs": 64364,
  "deliveryStatus": "not-requested"
}

PR fix notes

PR #81371: fix(cron): treat attempt dispatch as execution start

Description (problem / solution / changelog)

Fixes #81368

Summary

  • Treat attempt_dispatch as an isolated cron execution-start milestone.
  • Add a regression test proving the pre-execution watchdog is cleared after attempt_dispatch; the run then fails only at the configured job timeout.

Root cause

pi-embedded-runner can report attempt_dispatch, but isCronAgentExecutionStarted did not classify that phase as execution-started. For isolated cron runs that reach dispatch before the first model call, the 60s pre-execution watchdog could still abort the run as stalled.

Audits

  • Existing helper: reused isCronAgentExecutionStarted; no new classifier.
  • Shared caller: helper is private to src/cron/service/timer.ts and only broadens the set of positive execution milestones.
  • Rival scan: no open direct PR for #81368. #80923 is closed/superseded and was a large dirty branch; #80888 is closed but the beta.4 repro in #81368 shows the local hotfix is still needed.

Tests

  • pnpm format:check src/cron/service/timer.ts src/cron/service/timer.regression.test.ts
  • node scripts/test-projects.mjs src/cron/service/timer.regression.test.ts
  • pnpm check:test-types
  • git diff --check

Real behavior proof

  • Behavior or issue addressed: Isolated cron jobs that reach attempt_dispatch were still aborted by the 60s pre-execution watchdog as cron: isolated agent run stalled before execution start (last phase: attempt-dispatch), even though the configured job timeout was longer.
  • Real environment tested: Reporter live setup from #81368: OpenClaw 2026.5.12-beta.4 (d124625), npm global install, Linux, isolated cron job, delivery disabled, model openai/gpt-5.5. Local patch in this PR applies the same classifier change on current main.
  • Exact steps or command run after this patch: Reporter created the same no-delivery isolated cron job after applying the one-line case "attempt_dispatch": hotfix to the installed server-cron-*.js bundle and restarting the gateway:
openclaw cron add \
  --at "<now+15s ISO>" \
  --delete-after-run \
  --no-deliver \
  --session isolated \
  --agent cron \
  --model openai/gpt-5.5 \
  --timeout-seconds 240 \
  --message 'Run this exact shell command via exec: bash -lc "sleep 75". After it exits, reply exactly: OK_CRON_WATCHDOG_BETA4'
  • Evidence after fix: Copied live runtime output from #81368 after the same one-line classifier hotfix and gateway restart:
{
  "status": "ok",
  "summary": "OK_CRON_WATCHDOG_HOTFIX",
  "durationMs": 128739,
  "model": "gpt-5.5",
  "provider": "openai",
  "deliveryStatus": "not-requested"
}
  • Observed result after fix: The isolated cron run continued past the previous 60s false-stall cutoff and completed successfully at 128739ms with deliveryStatus: "not-requested".
  • What was not tested: I did not rerun the live OpenAI cron smoke from this workspace; the after-fix live evidence is the reporter runtime log from #81368. I locally verified this source patch with the focused cron regression shard and test typecheck.

Not changed

  • No watchdog duration changes.
  • No runner phase emission changes.
  • No cron scheduling or retry policy changes.

Changed files

  • src/cron/service/timer.regression.test.ts (modified, +82/-0)
  • src/cron/service/timer.ts (modified, +1/-0)

Code Example

openclaw cron add \
  --at "<now+15s ISO>" \
  --delete-after-run \
  --no-deliver \
  --session isolated \
  --agent cron \
  --model openai/gpt-5.5 \
  --timeout-seconds 240 \
  --message 'Run this exact shell command via exec: bash -lc "sleep 75". After it exits, reply exactly: OK_CRON_WATCHDOG_BETA4'

---

{
  "status": "error",
  "error": "cron: isolated agent run stalled before execution start (last phase: attempt-dispatch)",
  "durationMs": 64364,
  "deliveryStatus": "not-requested"
}

---

function isCronAgentExecutionStarted(info) {
   if (info.firstModelCallStarted) return true;
   switch (info.phase) {
+    case "attempt_dispatch":
     case "turn_accepted":
     case "process_spawned":
     case "tool_execution_started":

---

{
  "status": "ok",
  "summary": "OK_CRON_WATCHDOG_HOTFIX",
  "durationMs": 128739,
  "model": "gpt-5.5",
  "provider": "openai",
  "deliveryStatus": "not-requested"
}
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug / cron regression

Summary

This still reproduces on the latest release currently listed for users: v2026.5.12-beta.4 / OpenClaw 2026.5.12-beta.4 (d124625).

Related closed issue: #80888. I tried to reopen #80888 after posting the beta.4 evidence, but GitHub returned does not have the correct permissions to execute ReopenIssue, so I am opening this follow-up instead.

v2026.5.12-beta.4 appears to include the broader execution-milestone fix, but the packaged isCronAgentExecutionStarted() still does not treat attempt_dispatch as execution-started. In this environment, an isolated cron run can sit at attempt_dispatch past 60s and is killed by the pre-execution watchdog.

Environment

  • OpenClaw: 2026.5.12-beta.4 (d124625)
  • Install method: npm global, installed via official installer/update script
  • OS: Linux
  • Model/provider: openai/gpt-5.5
  • Job mode: isolated cron, delivery disabled

Repro

Create a no-delivery isolated cron job that deliberately runs longer than the old 60s watchdog window:

openclaw cron add \
  --at "<now+15s ISO>" \
  --delete-after-run \
  --no-deliver \
  --session isolated \
  --agent cron \
  --model openai/gpt-5.5 \
  --timeout-seconds 240 \
  --message 'Run this exact shell command via exec: bash -lc "sleep 75". After it exits, reply exactly: OK_CRON_WATCHDOG_BETA4'

Actual on beta.4 before local patch

{
  "status": "error",
  "error": "cron: isolated agent run stalled before execution start (last phase: attempt-dispatch)",
  "durationMs": 64364,
  "deliveryStatus": "not-requested"
}

Expected

Once the run reaches attempt_dispatch, the pre-execution watchdog should no longer kill it as "stalled before execution start". The job should continue until it finishes or hits the configured job timeout.

Local hotfix proof

Minimal local patch to the installed server-cron-*.js bundle:

 function isCronAgentExecutionStarted(info) {
   if (info.firstModelCallStarted) return true;
   switch (info.phase) {
+    case "attempt_dispatch":
     case "turn_accepted":
     case "process_spawned":
     case "tool_execution_started":

After applying that one-line patch and restarting the gateway, the same shape of no-delivery smoke job completed successfully past the 60s cutoff:

{
  "status": "ok",
  "summary": "OK_CRON_WATCHDOG_HOTFIX",
  "durationMs": 128739,
  "model": "gpt-5.5",
  "provider": "openai",
  "deliveryStatus": "not-requested"
}

Why this looks distinct from the closed state of #80888

#80888 was closed as fixed on main/current milestone logic. The latest release available to users, v2026.5.12-beta.4, still fails the live repro above. Either #80923's attempt_dispatch clearing needs to ship, or the current milestone implementation needs to emit an earlier execution-start phase for this path before the 60s pre-execution watchdog fires.

User impact

Longer isolated cron jobs can still be killed around 60s with a false attempt-dispatch stall error, even though the run is progressing and the configured job timeout is much longer.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Isolated cron watchdog still kills beta.4 runs at attempt_dispatch after 60s [1 pull requests, 2 comments, 3 participants]