openclaw - 💡(How to fix) Fix [Feature]: Per-job acceptSilentStop flag — treat stopReason=stop with payloads=0 as ok for cron jobs that intentionally produce no output [1 comments, 2 participants]

Problem

Cron jobs whose prompts say "if no work to do, output nothing" are marked as errors by the framework. The job runs fine, the model decides correctly that no action is needed, but because stopReason=stop with payloads.length=0 the run is classified as an "incomplete turn" — lastError: ⚠️ Agent couldn't generate a response. Please try again. is set, consecutiveErrors is incremented, and exponential error-backoff kicks in.

This forces every "silent cron" to either:

1. Inject a deterministic finalizer wrapper that always writes a side-effects.json file post-agent-run (extra script per cron), OR
2. Patch every prompt with an explicit "always emit a heredoc payload" rule, even when the semantically-correct behavior is to do nothing.

Both are tactical workarounds, not fixes.

Where the classification happens

dist/selection-D9uTvvsw.js:1249:

if (!incompleteTerminalAssistant && !reasoningOnlyAssistant
    && !emptyResponseAssistant && stopReason !== "error") return null;
return resolveAttemptReplayMetadata(params.attempt).hadPotentialSideEffects
    ? "⚠️ Agent couldn't generate a response. Note: some tool actions ..."
    : "⚠️ Agent couldn't generate a response. Please try again.";

isEmptyResponseAssistantTurn({ payloadCount: 0, ... }) returns true when the model emits only reasoning-blocks with no visible text and no tool calls — which is exactly what a "no work today" prompt should produce.

The error then propagates through runDueJob (dist/server.impl-*.js:3223) → consecutiveErrors increments (server.impl-*.js:3006, 3681) → backoff scheduling (server.impl-*.js:3349).

Proposed solution

Add an opt-in payload flag on cron-job definitions:

```json { "id": "my-silent-cron", "schedule": "0 6 * * *", "acceptSilentStop": true, "payload": { ... } } ```

When `acceptSilentStop === true` and the run terminates with `stopReason === "stop"` AND `payloads.length === 0` AND no tool errors, the framework should:

• mark the run `status: "ok"`
• reset `consecutiveErrors` to 0
• skip the "Agent couldn't generate a response" notification
• still record the run in `run-history.jsonl` for observability

Default remains current behavior (false) so existing crons are unaffected.

Use cases

• Daily-briefing crons that emit nothing on quiet days
• Heartbeat/inbox-scan jobs that legitimately have nothing to push
• Pre-meeting-briefing that suppresses output outside the trigger window
• Any "L1 detector → L2 reactive agent → Inbox" pipeline where the L2 agent decides not to enqueue (Pattern A)

Workaround in production

We currently ship a `_finalize.sh` wrapper next to every silent cron that writes `~/.openclaw/state/automations/<key>/side-effects.json` post-run. ~12 jobs across our deployment carry this wrapper purely to satisfy the non-empty-payload contract. A first-class `acceptSilentStop` flag would let us delete all of them.

Environment

• OpenClaw v2026.4.26 (still present)
• Self-hosted gateway + cron scheduler
• Affected jobs cross-channel (Telegram + iMessage outbox)

Refs

• Classification: `dist/selection-D9uTvvsw.js:1241-1250`
• Incomplete-turn handling: `dist/pi-embedded-aAN5CWPb.js:2858-2876`
• Error counter increment: `dist/server.impl-*.js:3681, 3006`
• Backoff: `dist/server.impl-*.js:3349`

Related

• #59765 (closed) — adjacent: empty content after think-block stripping; this request is distinct in that the cron is intended to produce no output.