Skip to content

Cron agentTurn jobs: timeouts + context truncation despite sessionTarget=isolated / maxMessages caps #22125

Description

@aicia-bot

Summary

Cron jobs running payload.kind=agentTurn against local models intermittently time out and/or hit context truncation failures, even when sessionTarget: "isolated" and payload.maxMessages/max_tokens are set.

Environment

  • OpenClaw CLI: 2026.2.19-2 (45d9b20)
  • Cron job: Aicia Gmail Monitor v2
    • schedule: every 5m (everyMs=300000)
    • sessionTarget: isolated
    • model: local/zai-org/glm-4.7-flash
    • payload.timeoutSeconds: 120
    • maxRunSeconds: 120
    • payload.maxMessages: 10
    • payload.max_tokens: 512

Observed behavior

From openclaw cron runs --id <jobId>:

  • Frequent errors: Error: cron: job execution timed out (typically at ~60000ms before we increased limits)
  • Also observed (returned as summary text):
    • Cannot truncate prompt with n_keep (11643) >= n_ctx (8192)
    • Connection error.
  • Some runs show unexpectedly huge prompt usage under a different provider/model:
    • provider: ollama, model: qwen3.5:397b
    • input_tokens: ~50k

Expected behavior

  • sessionTarget: isolated should prevent any history/prompt bloat across runs.
  • payload.maxMessages and payload.max_tokens should cap request size deterministically.
  • A job configured for a specific model should not silently execute under a different provider/model (or at least should log/flag this explicitly).

Questions / suspected issues

  1. Is maxMessages and/or max_tokens currently enforced for cron agentTurn jobs?
  2. Why can an isolated cron run still end up with a prompt that triggers n_keep >= n_ctx?
  3. Under what conditions will cron execute with a different provider/model than configured?
  4. Should payload.timeoutSeconds automatically set maxRunSeconds (they can diverge today)?

Repro (approx)

  1. Create cron job:
    • sessionTarget: isolated
    • payload.kind=agentTurn
    • model local/zai-org/glm-4.7-flash
    • short message instructing to run a local script
  2. Run at a tight interval (1–5 minutes)
  3. Observe timeouts and occasional context/truncation errors in run history.

Why this matters

This looks like the root cause behind "cron congestion" / recurring timeouts for local-model automation workloads.

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleMarked as stale due to inactivity

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions