mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-15 14:22:43 +00:00
9b72995a1d
get_due_jobs()'s one-shot stale-entry recovery (#38758) treated an expired run_claim (#59229) as proof the claiming tick died, but a run stalled on network I/O — or a laptop asleep mid-run — legitimately outlives the TTL while very much alive. The recovery then deleted the job record mid-flight: list showed the job gone, and when the run finished mark_job_run() found nothing to update, so last_run_at / last_status / last_delivery_error were never recorded. Two guards, per the liveness signals available: - Same process (the common single-gateway case): before removing a dispatch-limit-reached one-shot, consult the scheduler's running set via a lazy import; if the job is still running here it is slow, not stale — keep the entry. - Cross process: run_job's monitor loop now refreshes run_claim.at every 60s while the run is alive (including under HERMES_CRON_TIMEOUT=0, which previously blocked without polling), so an expired claim really does mean the owner died and the TTL stays a dead-owner detector. Fixes #62002 |
||
|---|---|---|
| .. | ||
| scripts | ||
| __init__.py | ||
| blueprint_catalog.py | ||
| jobs.py | ||
| lifecycle_guard.py | ||
| scheduler.py | ||
| scheduler_provider.py | ||
| suggestion_catalog.py | ||
| suggestions.py | ||