cron_run_logs can drop session_id, provider, and model on early agent failure #95873

Summary

When a cron agent run fails early during tool execution, cron_run_logs can record the wrapper timeout/error row without session_id, provider, or model.

That makes the failure look like an un-attributed cron timeout even when the underlying run had already resolved a concrete model/runtime and even when a real session artifact exists.

Environment

• OpenClaw 2026.6.8 (844f405)
• Linux / WSL2
• Observed on isolated cron agent runs

Observed behavior

For the same cron job (buffalo-fact), successful and failed rows differed like this:

manual:...:5  error                                duration_ms=94281  error=cron: job execution timed out (last phase: tool-execution-started)
manual:...:6  ok     openai  gpt-5.4  9216b0e8-... duration_ms=76937
manual:...:7  error                                duration_ms=94256  error=cron: job execution timed out (last phase: tool-execution-started)
manual:...:8  error                                duration_ms=94249  error=cron: job execution timed out (last phase: tool-execution-started)
manual:...:9  error                                duration_ms=94304  error=cron: job execution timed out (last phase: tool-execution-started)

Schema columns exist for these fields:

• session_id
• provider
• model

But the failed rows left them blank even though the underlying failed run did have a concrete session and model path.

Why this is misleading

In the same incident, the missing fields initially made the problem look like a generic cron timeout or pre-session failure.

After live investigation, the failed run was traceable to a concrete session:

• failed session id: fe78f578-0acc-4324-a4f9-4224950b0d9f
• provider/model path in session artifact: openai / gpt-5.4
• actual underlying failure: missing native Codex tool result during web_search

So the bookkeeping gap materially obscured root cause.

Expected behavior

Even when the embedded run later fails, cron_run_logs should persist whatever run metadata is already known, especially:

• session_id
• provider
• model
• ideally the underlying failure classification if available

At minimum, once a run session exists, the cron log row should not lose that identity on failure.

Suggested fix areas

• populate cron_run_logs metadata earlier in the run lifecycle
• preserve partially known run metadata when the final status becomes error
• avoid a failure path that writes only the wrapper cron error while dropping already-known run identity

Why this matters

This is an observability bug. It turns a debuggable model/tool failure into a vague cron timeout, forcing operators into transcript and live-log spelunking to recover the missing context.

Separate issue

This is distinct from the underlying missing_tool_result / incomplete-turn bug. That bug caused the failure; this issue is about why cron_run_logs obscured it.