fix(cron): stop one-shot CLI cron run from orphaning the job; reap dead-owner claims on tick

[teknium1]

Summary

Fixes #86721 — hermes cron run <job_id> from a one-shot CLI invocation orphaned the job: the run was background-dispatched onto a daemon thread of the calling process (when the CLI inherited a gateway/desktop session env and resolved a session key), the process exited immediately after printing Triggered job: ..., the runner died mid-LLM-call, the async delegation ended state='unknown', and the job's cron/executions.db row stayed status='claimed' forever — blocking every subsequent run of that job.

Fix

Two parts, matching the issue's expected behaviors (2) and (3):

1. One-shot CLI cron run executes synchronously to completion — hermes_cli/cron.py::_job_action("run", ...) now declares the delivery channel stateless (scoped _SESSION_ASYNC_DELIVERY set/reset around the call) before invoking the cron API. async_delivery_supported() then gates off _try_dispatch_background_run, so the run takes the existing synchronous path and the CLI blocks until the job finishes — the same treatment hermes -z already gets via declare_stateless_channel(). The declaration is token-scoped so in-process callers (tests, embedding apps) aren't tainted.

2. Dead-owner claim reclaim on the scheduler tick — execution rows already carry their owner pid + process start time, but recover_interrupted_executions() previously ran only at scheduler startup, so a claim orphaned while the gateway ticker was already running was never reaped. cron/scheduler.py::tick() now runs the recovery periodically (throttled to once per 300s so idle 60s ticks don't pay a ledger connection each cycle — same concern as fix(cron): skip idle config loads in scheduler tick #33612). Only rows whose exact owner process is provably dead (_owner_is_live: pid liveness + process start time match) are transitioned to unknown; live runs in other processes are never rewritten.

Tests

tests/cron/test_dead_owner_claim_reclaim.py (8 behavioral tests):

• the exact cron run from one-shot CLI orphans the job: async delegation dies with the calling process, execution stuck 'claimed' forever #86721 wedge: a claimed row owned by a real dead pid (finished subprocess) is cleared to unknown by a tick
• a running row from a dead owner is also reclaimed
• a claim owned by a live process survives the reap untouched
• the reap is throttled between back-to-back ticks and re-fires after the window expires
• a reap failure never breaks the tick
• CLI run action declares the channel stateless during the call and restores it after; non-run actions leave it alone
• end-to-end: _try_dispatch_background_run refuses background dispatch under a stateless channel even with an inherited HERMES_SESSION_KEY

Sabotage-verified: with the two fix files reverted to origin/main, all 8 tests fail; re-applying the fix greens them. Full tests/cron/ + tests/hermes_cli/test_cron.py + tests/tools/test_cronjob_run_background.py: 733 passed, 1 skipped.

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on e415c8b — fix(cron): stop one-shot CLI cron run from orphaning the j}

⚠️ Warnings

CI timings · View report · View job

Wall time 5m47s vs 3m43s (+55.6%). 11 job(s) slower, 13 faster,

• Python tests / Run tests slice 4/12: -44.0s
• Python tests / Run tests slice 12/12: -41.0s
• Python tests / Run tests slice 11/12: +38.0s
• Python tests / Run tests slice 7/12: -31.0s
• Python tests / Run tests slice 9/12: +21.0s

---

OSV vulnerability scan · View job

5 known vulnerabilities found in pinned dependencies.

• CVE-2026-67213 in package-lock.json
• CVE-2026-67213 in website/package-lock.json
• CVE-2026-70608 in package-lock.json
• CVE-2026-56876 in package-lock.json
• CVE-2026-70606 in package-lock.json

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.