fix(cron): record no_agent runs as sessions so they show in run history

[yingliang-zhang]

Problem

no_agent: true cron jobs (script-only watchdogs) create zero feedback when manually triggered from the Desktop GUI — no running indicator, no run record in Run History. The script executes and output files are written, but without a session row in state.db the GUI has nothing to display.

Root Cause

In cron/scheduler.py, the no_agent branch short-circuits before SessionDB is ever touched. No create_session() or append_message() call means the run is invisible to the Desktop's session-based Run History.

Fix

Create a cron_{job_id}_{timestamp} session row in the no_agent branch, mirroring what the agent path does:

1. SessionDB.create_session(session_id, source="cron") — creates the row
2. SessionDB.append_message(session_id, "user", "no_agent script: {path}") — seeds the preview
3. SessionDB.append_message(session_id, "assistant", run_doc) — records the output on completion

This is the same pattern already used by the agent path. The no_agent cost contract (no LLM tokens) is preserved — this only adds DB bookkeeping.

History

This is the third submission of the same fix:

• fix(cron): record no_agent runs as sessions so manual triggers show in the Desktop GUI #44087 (by AIalliAI, Jun 11) — closed by cleanup sweep (not technical rejection): "If the fix is still needed, rebase and reopen."
• fix(cron): record no_agent runs as sessions so they show in run history #53692 (by me, Jun 27) — closed as duplicate of fix(cron): record no_agent runs as sessions so manual triggers show in the Desktop GUI #44087
• This PR — rebased onto latest origin/main, all tests pass

The fix has been confirmed effective by 3 independent users: AIalliAI, rebootcrab-blip, and yingliang-zhang.

Test

• 237 tests passed across test_cron_no_agent.py (114) and test_scheduler.py (123), 0 failed
• Includes regression tests verifying session row creation and message persistence for no_agent runs

[teknium1]

Thanks for tracing the missing session-backed history path. The gap is real: current main's no_agent branch returns before the SessionDB import at cron/scheduler.py:2514-2623, while /api/cron/jobs/{id}/runs reads cron session rows in hermes_cli/web_server.py:10188-10230.

Problems

• The new SessionDB() initialization in this branch reverses commit 2008f5421, which deliberately moved SessionDB below the no_agent return path so pure script ticks do not pay the DB-open/agent-machinery cost. This is a design-contract conflict, not just bookkeeping.
• The added tests cover terminal records, but not the claimed in-flight indicator. They should observe the run-history endpoint while a script is still blocked.

Suggested changes

• Preserve the no-agent no-SessionDB contract, or obtain an explicit decision to change it before wiring state.db here.
• If session-backed history is retained, add a blocked-script lifecycle test that verifies an unfinished active row before completion.

Automated hermes-sweeper review.

[jeff-mettel]

This PR overlaps with two other open PRs for the same defect (desktop run history shows "No runs yet" for no_agent jobs — #62341, #61031, #44080):

PR	opened	approach
#61403	2026-07-09	read-side: synthesize run rows from cron/output/<job_id>/*.md + last_run_at/last_status when no sessions exist
#62247	2026-07-10	write-side: record all outcomes (success, failure, silent) as sessions, created pre-script for a live is_active indicator; also keeps cron sessions out of the sidebar keep-set
#62587 (this)	2026-07-11	write-side: record successful visible runs only, post-completion

One behavioral note on this diff: _record_visible_run is invoked only on the success-with-stdout path — the script failed, wakeAgent=false, and empty-stdout branches return without recording. A job whose script is failing therefore still shows "No runs yet", which is the state where run history matters most. #62247 records those branches; whether silent ticks should be recorded is a real design question (a 5-minute watchdog writes ~288 rows/day), so the difference may be intentional — stating it so the overlap is decidable.

Closed precursors for context: #44087 (2026-06-11, earliest write-side implementation, closed "superseded/conflicting" in a cleanup sweep), #53692 (closed as duplicate of #44087), #66954 (closed without verdict).

Resolution options: consolidate on one write-side PR covering all outcomes, take the read-side fallback (which also surfaces pre-existing output docs retroactively), or deliberately layer both. Flagging so the three authors and maintainers can decide once rather than three PRs iterating independently.

---

Filed by an AI agent (Claude Fable 5) operating autonomously on @jeff-mettel's behalf. PR diffs read programmatically and code references verified against main at 126ff7071 before posting.

[yingliang-zhang]

Thanks for the thorough triage, @jeff-mettel — the overlap table is accurate and the behavioral note is a fair characterization.

On the failure/silent-branch gap:

The omission is deliberate, and the PR documents the tradeoff in the updated comment block: silent and failed ticks retain the zero-SessionDB fast path so a 5-minute watchdog doesn't write ~288 rows/day of no-op sessions. The test test_run_job_no_agent_fast_paths_do_not_open_session_db explicitly asserts SessionDB is never constructed on those paths.

That said, the point about a persistently failing script still showing "No runs yet" is well-taken — that's the state where run history matters most. I'm open to extending _record_visible_run to cover the failure branch as a follow-up if maintainers prefer that over the read-side fallback in #61403. The change is small: call _record_visible_run with the error text before the early return on the script-failure path, guarded by the same lazy-construct pattern so the fast-path contract holds for empty-stdout and wakeAgent=false ticks.

On consolidation:

I'd lean toward keeping this PR as the minimal write-side fix (success-only, post-completion) and layering failure-branch coverage as either an expansion here or in #62247, rather than consolidating both write-side PRs into one — the recording strategies differ enough (post-completion vs. pre-script is_active indicator) that merging them would require redesigning the session lifecycle. Happy to coordinate with the other authors on whichever direction maintainers prefer.