Issue claims need heartbeat leases and stale-claim cleanup #268

Closed
opened 2026-07-06 12:49:34 -05:00 by jcwalker3 · 3 comments
Owner

The queue is deadlocking because many open issues carry status:in-progress even when no LLM session is actively working. A label alone is not enough proof of active work.

Required behavior:
An issue should block queue selection only if it has live proof:

  • recent heartbeat comment
  • open PR
  • recent branch push
  • explicit blocked status with current blocker
  • active owner/session metadata

Acceptance criteria:

  1. Claiming an issue posts a structured claim heartbeat.
  2. Long-running work must post progress heartbeats at least every 30 minutes.
  3. Queue inventory reports claim age, branch, owner/profile, PR, phase, blocker, and last heartbeat.
  4. Claims with no heartbeat after 30 minutes are marked stale in queue reports.
  5. Claims with no heartbeat after 60 minutes and no PR/recent branch become reclaimable.
  6. Claims with open PRs are reported as “awaiting review,” not stale.
  7. Phantom claims caused by failed mutation are detected and surfaced.
  8. Cleanup tool can propose stale-claim cleanup in dry-run mode.
  9. Cleanup mutation requires exact capability and posts a cleanup comment.
  10. Tests cover active claim, stale claim, reclaimable claim, open-PR claim, blocked claim, phantom claim, and failed claim mutation.
The queue is deadlocking because many open issues carry status:in-progress even when no LLM session is actively working. A label alone is not enough proof of active work. Required behavior: An issue should block queue selection only if it has live proof: - recent heartbeat comment - open PR - recent branch push - explicit blocked status with current blocker - active owner/session metadata Acceptance criteria: 1. Claiming an issue posts a structured claim heartbeat. 2. Long-running work must post progress heartbeats at least every 30 minutes. 3. Queue inventory reports claim age, branch, owner/profile, PR, phase, blocker, and last heartbeat. 4. Claims with no heartbeat after 30 minutes are marked stale in queue reports. 5. Claims with no heartbeat after 60 minutes and no PR/recent branch become reclaimable. 6. Claims with open PRs are reported as “awaiting review,” not stale. 7. Phantom claims caused by failed mutation are detected and surfaced. 8. Cleanup tool can propose stale-claim cleanup in dry-run mode. 9. Cleanup mutation requires exact capability and posts a cleanup comment. 10. Tests cover active claim, stale claim, reclaimable claim, open-PR claim, blocked claim, phantom claim, and failed claim mutation.
jcwalker3 added the status:in-progress label 2026-07-07 04:39:52 -05:00
Author
Owner

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: progress - issue: #268 - branch: feat/issue-268-heartbeat-leases - phase: pr-opened - profile: prgs-author - pr: #370 - blocker: none - next_action: await review
sysadmin removed the status:in-progress label 2026-07-07 08:36:57 -05:00
Author
Owner

Operator recovery reconciliation audit (session 2026-07-07)

Checked recovery leftovers from issues #51 / #76 / #304 against live queue state.

Issue Live state status:in-progress Open PR owner Disposition
#51 closed none n/a (landed via PR #52 / master ec9ddb0) Already reconciled; no mutation
#76 closed none PR #92 merged (Closes #76) Already reconciled; PR #99 is unrelated (#98)
#304 open present (legitimate) PR #388 open (Closes #304) Keep claim; do not close until PR #388 lands

gitea_reconcile_issue_claims + gitea_cleanup_stale_claims (dry-run): 0 stale/phantom/reclaimable claims; 12 status:in-progress issues all classified awaiting_review with linked open PRs.

Conclusion: prior recovery stale labels on #51/#76 are cleared; #304 claim is valid per #268 rule 6 (open PR ⇒ awaiting review, not stale). No cleanup mutations performed.

**Operator recovery reconciliation audit** (session 2026-07-07) Checked recovery leftovers from issues #51 / #76 / #304 against live queue state. | Issue | Live state | `status:in-progress` | Open PR owner | Disposition | |-------|------------|----------------------|---------------|-------------| | #51 | closed | none | n/a (landed via PR #52 / master ec9ddb0) | Already reconciled; no mutation | | #76 | closed | none | PR #92 merged (Closes #76) | Already reconciled; PR #99 is unrelated (#98) | | #304 | open | present (legitimate) | PR #388 open (Closes #304) | Keep claim; do not close until PR #388 lands | `gitea_reconcile_issue_claims` + `gitea_cleanup_stale_claims` (dry-run): **0** stale/phantom/reclaimable claims; **12** `status:in-progress` issues all classified `awaiting_review` with linked open PRs. Conclusion: prior recovery stale labels on #51/#76 are cleared; #304 claim is valid per #268 rule 6 (open PR ⇒ awaiting review, not stale). No cleanup mutations performed.
Author
Owner

Evidence update — Issue #390 showed why claim heartbeat/leases are needed.

The Issue #390 author handoff reported a same-worktree cross-session collision: another session worked in the same issue worktree, committed and opened PR #393 while the original session still had additional uncommitted/superset test work.

This shows status:in-progress and branch existence are not enough. Active ownership needs structured heartbeat/lease proof:

  • which session owns the issue
  • which worktree path is active
  • whether a PR exists
  • whether another session is allowed to take over
  • when the last activity occurred
  • whether the original session is still active

Expected heartbeat behavior:

  • claiming an issue posts owner/session/worktree/branch metadata
  • follow-up pushes require confirming the same lease or an explicit takeover
  • concurrent sessions must not silently co-build in the same worktree
  • queue reports should distinguish active claim, PR-backed claim, stale claim, and takeover-needed state
Evidence update — Issue #390 showed why claim heartbeat/leases are needed. The Issue #390 author handoff reported a same-worktree cross-session collision: another session worked in the same issue worktree, committed and opened PR #393 while the original session still had additional uncommitted/superset test work. This shows `status:in-progress` and branch existence are not enough. Active ownership needs structured heartbeat/lease proof: - which session owns the issue - which worktree path is active - whether a PR exists - whether another session is allowed to take over - when the last activity occurred - whether the original session is still active Expected heartbeat behavior: - claiming an issue posts owner/session/worktree/branch metadata - follow-up pushes require confirming the same lease or an explicit takeover - concurrent sessions must not silently co-build in the same worktree - queue reports should distinguish active claim, PR-backed claim, stale claim, and takeover-needed state
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#268