Skip to content

Cron isolated session false positive: tool-level error marks run as failed despite successful execution #91532

Description

@jonah791

Bug Description

When a cron job with sessionTarget: "isolated" runs a long multi-turn session (70+ tool calls including exec, write, edit, wiki_apply) and completes successfully with stopReason: "stop", OpenClaw sometimes still marks the run as status: "error" with a generic error message.

Steps to Reproduce

  1. Create a cron job with sessionTarget: "isolated", lightContext: true
  2. The cron prompt instructs the agent to run multiple exec calls (e.g., check ComfyUI, build workflow JSON, curl POST to API, poll /history), write/edit files, and wiki_apply
  3. All tool calls succeed, model finishes with stopReason: "stop"
  4. OpenClaw reports status: "error" with:
    • source: "tool" -> "LLM request failed" (first cron)
    • source: "tool" -> "⚠️ ⏰ Cron failed" (second cron)

Expected Behavior

Cron runs where the agent completed successfully (all tool calls returned without isError, model stopReason: "stop") should be marked as status: "ok" and delivered normally.

Actual Behavior

The run is marked as status: "error" with:

  • deliveryStatus: "not-delivered"
  • deliveryError: "LLM request failed" / "⚠️ ⏰ Cron failed"
  • The cron's consecutiveErrors counter increments unnecessarily
  • A failure notification is sent to the user despite the task having completed

Evidence

From the cron run diagnostics, two distinct failure modes were observed:

Mode A ("LLM request failed") - The exec tool returned Command still running (non-blocking async), but the model side's request was aborted while waiting for the next tool result. The exec command had no explicit timeout parameter, causing the model to wait indefinitely.

Mode B ("Cron failed") - All tool calls completed successfully, the model finished with stopReason: "stop", but the cron runner still flagged the run as failed. This appears to be a false positive in the post-run state check.

Key evidence from the session history:

  • Cron 1: 70+ tool calls completed, workflow submitted to ComfyUI API successfully, final exec returned "Command still running" and then the model request was aborted
  • Cron 2: All 10+ tool calls completed, model finished with stopReason "stop", yet still reported as failed

Diagnostics

The error diagnostics only show:

{
  "entries": [
    { "source": "tool", "severity": "error", "message": "LLM request failed." },
    { "source": "agent-run", "severity": "error", "message": "LLM request failed." }
  ]
}

No tool name, no arguments, no underlying error message.

Key Issues

  1. False positives for completed runs: The cron runner's post-execution check flags runs as failed even when the agent finished normally
  2. Generic error messages: "LLM request failed." and "⚠️ ⏰ Cron failed" provide no actionable diagnostic information
  3. No tool-level error context: When source: "tool" is reported, the diagnostics should include the tool name and the actual error
  4. Failure notifications for successful tasks: Users receive misleading failure alerts

Suggested Fix

  1. In the cron completion check, verify that the agent actually stopped with an error before marking the run as failed. If stopReason: "stop" and no tools returned isError: true, the run should be considered successful.
  2. Include the failing tool's name and the original error message in diagnostics when source: "tool"
  3. Differentiate between:
    • "LLM preflight timeout" (provider was unavailable at session start)
    • "LLM request failed during execution" (model request aborted mid-task)
    • "Cron post-run state check error" (false positive)
  4. For Mode A, consider adding a default timeout to exec calls in cron sessions, or make the cron runner more resilient to transient model request aborts

Environment

  • OpenClaw version: Latest (June 2026)
  • Platform: Windows 11 25H2
  • Model: opencode/deepseek-v4-flash
  • Node.js: v24.14.0

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions