Cairn

Cron fire-fence timeout vs ownership loss correction

NousResearch/hermes-agent · cluster 108341

Data as of

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

The short answer

0open issues
0open PRs
6items grouped
Known?
Yes. 6 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.

These issues and PRs address a bug where a local fire-fence timeout during heartbeat renewal was incorrectly treated as loss of fire-claim ownership, causing slow or fenced deliveries to be falsely recorded as failed. The work focuses on correctly distinguishing fire-fence contention from actual ownership loss.

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

4 PRs closed without merging

From the close comments: done elsewhere 2 · other 2

  • #108359 fix(cron): renew fire-claim heartbeat without fire-fence timeout (fixes #108341) · done elsewhere → 9a60a7f, #108341
  • #108360 fix(cron): distinguish fire fence contention from ownership loss · other → #108359
  • #108471 fix(cron): remove unnecessary fire_fence_lock in heartbeat_fire_claim · done elsewhere → 9a60a7f
  • #127874 fix(cron): an unacquirable fire fence is not lost fire-claim ownership · other
Closed issues · 1
  • Closed#108341cron: fire-claim heartbeat treats a local fire-fence timeout as ownership loss, so a slow notifying delivery is recorded as failed
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.33: 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
4 PRs closed without merging
Fix link checked
12 Sep 2026

For your agent

The same facts, typed.

cluster/108341.json
cluster/108341.md