Fix: Kimi K2.5 Cron Jobs Fail with SSE Stream Event Order Errors

Problem

Cron jobs using kimi-coding/k2p5 via OpenRouter fail with ~80% frequency due to out-of-order SSE events in the streaming response parser:

Unexpected event order, got message_start before receiving "message_stop"
Unexpected event order, got content_block_stop before "message_start"

Setting agents.defaults.blockStreamingDefault: "on" does not resolve the issue — the error persists even in blocking mode, suggesting the stream parser does not fully flush or reset state between isolated cron sessions.

Workarounds

Option 1: Switch cron jobs to non-streaming mode (Recommended)

Force the cron payload to use blocking (non-streaming) requests by passing stream: false explicitly:

{
  "id": "b393d508-ec9a-4b6d-bb97-7f584eb0ef83",
  "name": "fpl-daily-check",
  "schedule": { "kind": "cron", "expr": "0 12 * * *", "tz": "Europe/London" },
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "message": "Run FPL check...",
    "model": "kimi-coding/k2p5",
    "stream": false
  }
}

If stream: false is not yet a supported payload field, fall back to Option 2.

Option 2: Add retry logic with exponential backoff

Wrap cron execution with a retry shell script to absorb the ~80% failure rate until a proper fix lands:

#!/bin/bash
# retry-cron.sh
JOB_ID="b393d508-ec9a-4b6d-bb97-7f584eb0ef83"
MAX_RETRIES=5
DELAY=10

for i in $(seq 1 $MAX_RETRIES); do
  echo "Attempt $i..."
  openclaw cron run --job-id "$JOB_ID" --mode force && exit 0
  echo "Failed. Retrying in ${DELAY}s..."
  sleep $DELAY
  DELAY=$((DELAY * 2))
done

echo "All $MAX_RETRIES attempts failed."
exit 1

Update your crontab to call the script instead of openclaw directly:

0 12 * * * /home/user/retry-cron.sh >> /var/log/openclaw-cron.log 2>&1

Option 3: Switch to a more stable provider for cron jobs

If Kimi K2.5 is not strictly required for these workflows, use Anthropic or OpenAI models which have stable SSE implementations:

{
  "payload": {
    "kind": "agentTurn",
    "message": "Run FPL check...",
    "model": "anthropic/claude-sonnet-4-6"
  }
}

Use Kimi K2.5 for interactive sessions where a retry is trivial, and reserve cron jobs for providers with reliable stream ordering.

Option 4: Defensive stream parser patch (Advanced)

If you are running a self-hosted or patched build, add state reset logic to the SSE parser so it recovers gracefully when message_start arrives before message_stop:

// stream-parser.ts (pseudocode — adapt to actual source)
function handleEvent(event: SSEEvent) {
  if (event.type === "message_start" && this.state !== "idle") {
    // Kimi K2.5 may send message_start without prior message_stop
    console.warn("Stream reset: message_start received before message_stop — resetting parser state")
    this.reset() // flush current state before processing new message
  }

  if (event.type === "content_block_stop" && this.state === "idle") {
    // Discard orphaned content_block_stop events
    console.warn("Stream warning: content_block_stop received before message_start — discarding")
    return
  }

  this.processEvent(event)
}

Verification

After applying Option 1 or Option 2:

# Force-run the job 5 times and check failure rate
for i in {1..5}; do
  openclaw cron run --job-id b393d508-ec9a-4b6d-bb97-7f584eb0ef83 --mode force
  echo "---"
done

A successful fix should reduce the failure rate from ~80% to 0%.

Upstream Fix Required

The SSE normalisation layer needs the same hardening applied for reasoning_content in #38669 / #39907 / #40552:

1. Tolerate message_start without prior message_stop — reset parser state and continue
2. Discard orphaned content_block_stop events — log a warning, do not throw
3. Add provider-specific SSE quirk flags — allow per-provider tolerances in openclaw.json

Suggested config once implemented:

{
  "providers": {
    "kimi-coding": {
      "sseQuirks": {
        "tolerateOutOfOrderEvents": true
      }
    }
  }
}

Environment

References

• Related fixes: #38669, #39907, #40552
• blockStreamingDefault: "on" does not resolve this issue
• Kimi K2.5 interactive sessions are unaffected — issue is specific to isolated cron sessions