openclaw - 💡(How to fix) Fix Cron: per-job configurable stuck-session threshold (currently hardcoded 120s causes false positives on legitimately slow jobs) [1 comments, 1 participants]

Summary

The stuck-session detector emits stuck session: ... age=Ns queueDepth=0 warnings when a session's state=processing exceeds 120 seconds. The threshold appears hardcoded (or at least not user-configurable per-job), which generates false positives for cron jobs that are legitimately long-running by design.

Repro

Cron job that calls a remote service (e.g., a Supabase sync that processes 2k pages) routinely takes 2-3 minutes per run. The job completes successfully (status=ok in ~/.openclaw/cron/runs/<job-id>.jsonl), but the detector logs 1-3 stuck session warnings during the run window.

In my deployment:

~/.openclaw/cron/jobs.json defines 8 jobs. Two of them (GBrain Sync every 15min,
GBrain Daily Report every 24h) hit this regularly. ~12 false-positive stuck
warnings per hour during sync windows.

Sample log:

{"1":"stuck session: sessionId=2072e9d7-9b6b-4a1e-a10d-c8c01af5f84d sessionKey=agent:main:cron:616d2c20-... state=processing age=148s queueDepth=0", ...}

The job completed with status=ok shortly after.

Why this matters

External tooling that monitors stuck session log lines (dashboards, alerting bots, my /gbrain health skill) gets noisy alerts that aren't actionable. Users are forced to either:

• Accept noise and lose trust in the detector signal (eventual alert fatigue → real stucks ignored).
• Build local workarounds (whitelists, classifiers) that mask the upstream signal — wrong direction; signal-suppression at downstream is fragile and hides real bugs when whitelist drifts.

The clean fix is upstream: let cron/jobs.json declare an expected duration per job.

Proposed shape

Extend cron/jobs.json with optional stuckThresholdMs per job:

{
  "id": "616d2c20-d06d-4116-830b-2b097b6fe819",
  "name": "GBrain Sync",
  "schedule": { "kind": "cron", "expr": "*/15 * * * *" },
  "stuckThresholdMs": 300000,   // <-- new: 5min for this job
  "enabled": true
}

Behavior:

• If stuckThresholdMs is unset → use the existing default (120000 ms / 120s).
• If set → detector uses the per-job value when computing age > threshold ⇒ stuck.
• Backward-compatible: existing jobs continue working unchanged.

Optionally a global override: gateway.stuckThresholdMs defaulting to 120000.

Why per-job (not global)

A global bump would mask real stucks in fast jobs (e.g., interactive Telegram sessions) where 120s is correctly aggressive. Per-job lets each kind of work have its own SLA.

Related issues

• #71127 — stuck-processing sessions detected but never aborted. Different concern (recovery), but same surface; once aborted, this issue's stuckThresholdMs would tune when that abort fires for non-interactive crons.
• #68620 — single hung tool blocking session for 49 min. Per-job thresholds help here too: a cron with stuckThresholdMs: 600000 makes the abort window explicit.
• #39141 — optional session activity watchdog. Adjacent — this issue is the configuration layer that watchdog needs.

Acceptance criteria

1. Schema validation: cron/jobs.json accepts optional stuckThresholdMs: number per job, validates [1000, 3600000] range.
2. Detector reads the value at session-start, applies per-session.
3. Default behavior unchanged when field absent.
4. Doctor / status output surfaces the active threshold per job for transparency.
5. Migration is no-op for existing brains.

Workaround in the meantime

Downstream tooling that needs to filter false positives can correlate stuck session events with cron/runs/<job-id>.jsonl status=ok entries, but this is fragile and signals the canonical detector is too aggressive for some jobs.

Happy to send a PR if the shape is acceptable.