openclaw - 💡(How to fix) Fix [Bug] Cron job reports status 'ok' immediately after sessions_yield, before subagent completes [1 comments, 2 participants]

Summary

When a cron job with sessionTarget: isolated calls sessions_yield after spawning a subagent, the cron infrastructure immediately marks the job as status: "ok" and records a short durationMs (~25 seconds), even though the subagent continues running for several minutes and the parent session later resumes to process the result.

This is a monitoring/observability bug — the work completes successfully, but the cron job's recorded status and duration are misleading.

Version

OpenClaw 2026.4.28 (latest)

Steps to Reproduce

1. Create a cron job with sessionTarget: "isolated" and payload.kind: "agentTurn"
2. In the agent turn: a. Write a timestamp to a file b. Spawn a subagent with a task that sleeps for 180 seconds: sleep 180 && echo "done" >> file.txt c. Call sessions_yield to yield to the subagent
3. Observe the cron run log

Expected Behavior

The cron job should remain in a "running" state until the subagent completes and the parent session finishes processing, OR the durationMs should reflect the actual total time including subagent execution.

Actual Behavior

From the cron run log (~/.openclaw/cron/runs/<job-id>.jsonl):

{
  "action": "finished",
  "status": "ok",
  "durationMs": 25182,
  "runAtMs": 1777410618539
}

But the subagent ran for 3+ minutes (180 seconds sleep + overhead). The parent session transcript shows:

• Parent yields at 21:10:43
• Subagent completion event arrives at 21:13:54 (3m11s later)
• Parent resumes and reads file at 21:13:58

The cron infrastructure recorded the job as "finished" at ~21:10:43 (25s after start), but the actual work didn't complete until ~21:14:01.

Impact

• False positives in monitoring: Cron jobs appear to succeed quickly when they're actually still running
• Incorrect duration metrics: Makes it impossible to track actual job execution time
• Confusing debugging: The cron run log says "ok" but the subagent may still be running or may fail later

Related Issues

• #46298 (closed) — sessions_yield terminates isolated cron sessions — this was about the session actually dying; our session survives and completes
• #49572 (closed) — sessions_yield only survives one LLM turn — this was about aborting after one turn; our session continues for multiple turns

This appears to be a new variant where the cron infrastructure prematurely marks the job as finished while the underlying session continues.

Workaround

None known. The work completes successfully, but cron monitoring is misleading.