fix(cron): end-to-end fix for cron session rendering on Hermes Desktop

[ValentinSergief]

Problem

Cron sessions on Hermes Desktop are unviewable after the run: clicking a completed cron job shows only the user prompt, with tool calls and the LLM response invisible until a full gateway restart. Two bugs in the resume pipeline cause it.

Root cause

1. cron/scheduler.py — shutdown could block the inactivity watchdog — pool.shutdown(wait=True) runs before the _inactivity_timeout branch calls agent.interrupt(). If the future is the hung operation the watchdog detected, shutdown blocks indefinitely and the interrupt never runs.

2. tui_gateway/server.py — tool-call-only assistant frames dropped — _history_to_messages skips every assistant message with empty content, which is every tool-invocation frame. The resume payload loses the tool chain — and worse, the synthesized tool frames don't carry tool_call_id, so the desktop can't pair a tool result with the call that produced it.

Fix

1. wait=False (+ cancel_futures=True) on both _cron_pool.shutdown sites — the inactivity branch is always reachable and is responsible for killing stuck agents. Update (2026-08-19): this half is now also present upstream, landed via a separate contributor's PR; it is kept here for the record. The tool-call half below is the still-novel part.

2. _history_to_messages preserves assistant frames that carry tool_calls even with empty content, and the synthesized tool frames now carry the original tool_call_id. The raw result payload is deliberately NOT forwarded — tool output can contain secrets, and the desktop transcript stays redacted. The link is kept, the leak is not.

Tests

• test_watchdog_can_fire_after_shutdown_does_not_block — regression for the shutdown ordering
• test_history_to_messages_preserves_tool_calls_for_resume_display + test_history_to_messages_preserves_tool_calls_on_assistant_frame — tool-call frames and the id link survive
• 7/7 in test_cron_inactivity_timeout.py; serializer tests in test_tui_gateway_server.py

[tonydwb]

Code Review Summary

Verdict: Approved

Looks Good:

• End-to-end fix for cron session rendering on Hermes Desktop. The issue was that cron job output was not being properly streamed to the Desktop chat interface, causing blank or missing session content.
• Fixes include proper handling in the desktop controller, session message streaming, and cron scheduler.
• 8 files, +140/-17. Changes span desktop React components, cron/scheduler.py, hermes_state.py, and tui_gateway.
• Includes test coverage.

Reviewed by Hermes Agent

[ValentinSergief]

Verified compatible with #44630 (composer status stack + subagent windows). Tested in local build with both sets of changes — no conflicts, all features coexist cleanly.

[teknium1]

Thanks for tracing the Desktop resume pipeline. Two current-head behaviors support the core report: tui_gateway/server.py:4939-4950 drops empty assistant tool-call frames, and apps/desktop/src/app/session/hooks/use-session-actions/index.ts:550-559 prefers any non-empty REST snapshot over the resume payload.

Problems

• cron/scheduler.py:3208 in this PR changes shutdown to wait=True, but the inactivity branch calls agent.interrupt() only after this finally block. A hung future will therefore block before the watchdog can interrupt it.
• _cron_emit is initialized to None at cron/scheduler.py:2771 and is never assigned in this diff; the new completion branches cannot emit. _cron_emit_map is also not defined by the patch.
• The PR changes list_cron_job_runs semantics with ended_at IS NOT NULL but adds no test, and the stated SQLite synchronous=FULL change is not present in the diff.
• No regression tests are included. Current tests/test_tui_gateway_server.py:915-941 explicitly expects the tool-call-only assistant frame to be omitted.

Suggested changes

• Preserve a non-blocking, bounded inactivity cleanup path before waiting on the worker.
• Rework or remove the incomplete cron event-emitter wiring, then add lifecycle coverage.
• Add serializer and Desktop resume-order regression tests; cover any intended active-versus-completed cron-run listing behavior.

Automated hermes-sweeper review.

[ValentinSergief]

Comment anchored to an earlier commit. The current head (bc66d193) uses wait=False, cancel_futures=True on both _cron_pool.shutdown sites, so the inactivity branch's agent.interrupt() is always reachable — test_watchdog_can_fire_after_shutdown_does_not_block covers the exact path. The _history_to_messages serializer keeps the tool_call_id link on synthesized tool frames while deliberately not forwarding raw tool output (the desktop transcript stays redacted); test_history_to_messages_preserves_tool_calls_on_assistant_frame and the updated resume-display test cover both.

[ValentinSergief]

One more review point for the record: the _cron_emit/_cron_emit_map initialization concern applied to the earlier 8-file head. The consolidated head drops that emission mechanism entirely – the completion branches emit directly through the session/desktop resume path – so there is nothing to initialize. The resume-display and tool-call preservation tests cover the resulting behavior.