NousResearch/hermes-agent

Cron recovery misidentifies live owner on start-time drift

Cluster 117505. Data as of 2026-10-26 12:29 UTC

Nothing open on GitHub. Fix merged in #117584 on 20 Sep 2026. Check it covers your case.

open issues

open PRs

items grouped

Known?: Yes. 3 related items grouped here, 1 issue already closed.
Fix event: A fix was merged to main in PR #117584. Check it covers your case. No release data is tracked.
Tracker: The maintainers' tracker marks this resolved, deciding PR #117584. That is separate from the fix event.
Still open: Nothing open on GitHub.

Next step: read #117584, then check it covers your case.

Read #117584 Pick up a Lab task

These items address a bug where cron's recovery logic incorrectly rejects a live process as the owner when its start-time fingerprint differs by a small amount (e.g., one second), causing running executions to be marked unknown. The fix treats a drifted-but-close start-time as still belonging to a live owner.

Open issues0

No open issues.

Open PRs0

No open pull requests.

Fixes on record

Merged to main. A stamp counts the issues a fix is linked to.

#117584 fix(cron): recovery keeps a live owner whose start-time fingerprint drifted by a second (#117505, salvage #117514)

merged to main

files: cron/executions.py, gateway/delivery_ledger.py, gateway/platforms/api_server_runs.py, gateway/status.py, tests/cron/test_owner_start_time_drift.py, tests/gateway/test_owner_liveness_drift.py, tools/async_delegation.py

1 PR closed without merging

From the close comments: merged via another change 1

#117514 fix(cron): treat a drifted start-time fingerprint as a live owner in recovery · merged via another change → 36ede56, #117584

Closed issues · 1

Closed#117505cron: _owner_is_live() rejects a live process on an exact start-time compare, marking running executions unknown

How this cluster was grouped

Link evidence (structural links throughout): every member is connected by structural evidence: shared changed files, or a closing/superseded reference.
Pairwise link density 0.67: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36. 1.00 means every pair is linked.

Pick up a Lab task

Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.

Open the Lab

At a glance

Merged PRs: #117584
Closed issues: 1
Attempts: 1 PR closed without merging
Fix link checked: 20 Sep 2026

For your agent

The same facts, typed.

cluster/117505.json
cluster/117505.md