mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-04-30 01:41:43 +00:00
7c63c24613
If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes #16265 |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| test_codex_execution_paths.py | ||
| test_cron_context_from.py | ||
| test_cron_inactivity_timeout.py | ||
| test_cron_script.py | ||
| test_cron_workdir.py | ||
| test_file_permissions.py | ||
| test_jobs.py | ||
| test_scheduler.py | ||