Cron fire-fence deadlock and false ownership-loss corrections

NousResearch/hermes-agent · cluster 100401

Data as of 2026-10-23 11:54 UTC

Nothing open on GitHub. Fix merged in #109310. Check it covers your case.

open issues

open PRs

items grouped

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

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

Read #109310 Pick up a Lab task

These changes address a bug where cron jobs running longer than ~60 seconds deadlock on their own fire fence, producing false 'ownership lost' or 'interrupted by shutdown' errors. The corrections separate fire-fence contention from genuine claim ownership loss so long-running deliveries are no longer incorrectly marked as failed.

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.

#109310 fix(cron): long fenced deliveries no longer recorded as failed 'ownership lost' (#108341, #100401; salvage #106745)

merged to main

files: cron/jobs.py, tests/cron/test_claim_job_for_fire.py

3 PRs closed without merging

From the close comments: done elsewhere 3

#100418 fix(cron): don't treat a busy fire fence as lost claim ownership · done elsewhere → 9a60a7f
#109003 fix(cron): separate fire-fence contention from fire-claim ownership loss · done elsewhere → 9a60a7f
#109083 fix(cron): don't wait on the fire fence to renew a live fire claim · done elsewhere → 9a60a7f

Closed issues · 1

Closed#100401[Bug]: cron — fire-claim heartbeat deadlocks on its own run's fence, killing every job that runs >60s as "Interrupted by shutdown"

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.40: 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: #109310
Closed issues: 1
Attempts: 3 PRs closed without merging
Fix link checked: 12 Sep 2026

For your agent

The same facts, typed.

cluster/100401.json
cluster/100401.md