Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 73 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

Add non-destructive recovery for pushed branches after lost issue locks #440

New Issue
Closed
opened 2026-07-07 12:28:34 -05:00 by jcwalker3 · 3 comments
jcwalker3 commented 2026-07-07 12:28:34 -05:00
Owner
Copy Link
Copy Source

Problem

During issue #420, the author completed and pushed branch feat/issue-420-server-code-parity at commit 934688a, but the MCP server restarted before PR creation and wiped the in-memory issue lock.

After restart:

  • gitea_create_pr refused to create the PR because the live issue lock was missing.
  • gitea_lock_issue refused to reacquire the lock because a remote branch matching issue-420 already existed.
  • The branch was the author’s own pushed work, but the duplicate-work guard treated it as a blocker.
  • The proposed recovery path required deleting the remote branch, then re-running lock → push → create PR.

This is unsafe. Recovery from a stale or missing lock should not require destructive remote branch deletion.

Acceptance Criteria

  1. Issue locks must survive MCP server restarts, or recovery must be explicitly supported.
  2. A pushed branch for the same issue must not automatically deadlock lock reacquisition.
  3. Recovery must be non-destructive by default.
  4. gitea_lock_issue must distinguish:
    • another session’s competing branch
    • the same actor/session recovering its own already-pushed branch
    • an existing open PR
    • a stale branch with no active lock
  5. gitea_create_pr should support a safe recovery/adoption path for an already-pushed branch when ownership and safety checks pass.
  6. Duplicate branch detection must not rely only on broad substring matching like issue-420; it should use structured issue/branch ownership evidence where possible.
  7. Add tests for:
    • lock lost after server restart with branch already pushed
    • same actor recovering the branch and creating the PR
    • competing actor blocked from adopting the branch
    • existing PR detection preventing duplicate PR creation
    • stale branch recovery without branch deletion
  8. Update workflow docs so author sessions do not request destructive branch deletion as the normal recovery path.

Observed Case

## Problem During issue #420, the author completed and pushed branch `feat/issue-420-server-code-parity` at commit `934688a`, but the MCP server restarted before PR creation and wiped the in-memory issue lock. After restart: * `gitea_create_pr` refused to create the PR because the live issue lock was missing. * `gitea_lock_issue` refused to reacquire the lock because a remote branch matching `issue-420` already existed. * The branch was the author’s own pushed work, but the duplicate-work guard treated it as a blocker. * The proposed recovery path required deleting the remote branch, then re-running lock → push → create PR. This is unsafe. Recovery from a stale or missing lock should not require destructive remote branch deletion. ## Acceptance Criteria 1. Issue locks must survive MCP server restarts, or recovery must be explicitly supported. 2. A pushed branch for the same issue must not automatically deadlock lock reacquisition. 3. Recovery must be non-destructive by default. 4. `gitea_lock_issue` must distinguish: * another session’s competing branch * the same actor/session recovering its own already-pushed branch * an existing open PR * a stale branch with no active lock 5. `gitea_create_pr` should support a safe recovery/adoption path for an already-pushed branch when ownership and safety checks pass. 6. Duplicate branch detection must not rely only on broad substring matching like `issue-420`; it should use structured issue/branch ownership evidence where possible. 7. Add tests for: * lock lost after server restart with branch already pushed * same actor recovering the branch and creating the PR * competing actor blocked from adopting the branch * existing PR detection preventing duplicate PR creation * stale branch recovery without branch deletion 8. Update workflow docs so author sessions do not request destructive branch deletion as the normal recovery path. ## Observed Case - **Issue**: #420 - **Branch**: `feat/issue-420-server-code-parity` - **Commit**: `934688a` - **Cause**: server restart wiped in-memory issue lock after branch push - **Result**: lock/PR creation deadlock
jcwalker3 added the status:in-progress label 2026-07-07 15:39:26 -05:00
jcwalker3 commented 2026-07-07 15:39:27 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #440 - branch: feat/issue-440-lock-recovery - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
jcwalker3 commented 2026-07-07 15:40:35 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #440 - branch: feat/issue-440-branch-recovery - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
jcwalker3 removed the status:in-progress label 2026-07-07 15:44:13 -05:00
jcwalker3 commented 2026-07-07 15:45:57 -05:00
Author
Owner
Copy Link
Copy Source

Deferred (umbrella). PR #466 marked superseded/blocked; author claim released. Work proceeds via dependency PRs #465/#443, #461/#442, #464/#438. Revisit #440 after those land.

**Deferred (umbrella).** PR #466 marked superseded/blocked; author claim released. Work proceeds via dependency PRs #465/#443, #461/#442, #464/#438. Revisit #440 after those land.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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