Teknium d345b9fbfe refactor(cron): derive one-shot run-claim TTL from HERMES_CRON_TIMEOUT (#59567) ... Follow-up to #59524. The one-shot running-claim stale-recovery window was a fixed 30-min constant. Derive it from the cron inactivity timeout instead (HERMES_CRON_TIMEOUT, the same limit the scheduler enforces per run) so the safety valve tracks how long a run may actually go quiet: - unset/invalid -> default 600s inactivity -> TTL 1800s (unchanged behaviour) - positive N -> max(N * 3 headroom, 1800s floor) - 0 (unlimited) -> no finite bound -> fall back to the 1800s constant The fixed constant is kept as the floor + unlimited-case fallback. Resolved once per due-scan. HERMES_CRON_TIMEOUT is a pre-existing internal env var (already read by cron/scheduler.py); no new config surface. E2E: with HERMES_CRON_TIMEOUT=1200 the claim now survives to 60min where the old fixed 1800s constant wrongly expired it at 30min mid-run. +1 derivation test; 640/640 cron tests pass.		2026-07-06 04:57:09 -07:00
..
scripts	…
__init__.py	…
blueprint_catalog.py	…
jobs.py	refactor(cron): derive one-shot run-claim TTL from HERMES_CRON_TIMEOUT (#59567)	2026-07-06 04:57:09 -07:00
lifecycle_guard.py	fix(gateway,cron): guard cron model-tool path + add auto-resume loop breaker (#30719)	2026-07-01 02:48:36 -07:00
scheduler.py	fix(cron): deliver before tearing down the agent's async clients (#58720)	2026-07-06 02:05:46 +05:30
scheduler_provider.py	…
suggestion_catalog.py	…
suggestions.py	…