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

Reviewer workflow must stop before approval when PR head is already landed #292

New Issue
Closed
opened 2026-07-07 00:14:23 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-07 00:14:23 -05:00
Owner
Copy Link
Copy Source

Reviewer workflows need a hard gate for PRs whose head commit is already an ancestor of the target branch.

Observed failure

A reviewer workflow processed PR #278 and validated the branch successfully. However, diagnostics showed that PR head commit 2a544b78d1371925761d16f1c451bb3b2984470e was already present on master.

Despite that, the workflow:

  • submitted an APPROVED review
  • attempted to merge PR #278
  • received a Gitea API HTTP 405 merge failure
  • then concluded the PR was already landed and required manual reconciliation

Problem

If a PR head is already landed on the target branch, the PR is no longer a normal review/merge candidate. Approval and merge should be blocked. The workflow should enter an ALREADY_LANDED_RECONCILE_REQUIRED state instead.

Required behavior

  1. After selecting and pinning a PR head SHA, check whether the PR head is already an ancestor of the target branch.
  2. If the PR head is already landed:
    • do not approve
    • do not request changes unless there is a real blocker
    • do not merge
    • do not attempt the merge API
    • produce a reconciliation handoff
  3. The reconciliation handoff must include:
    • PR number/title
    • PR head SHA
    • target branch
    • proof that head SHA is already ancestor of target
    • linked issue status
    • recommended close/reconcile action
    • required capability checks for any close/comment/issue mutation
  4. Any PR-close or issue-close action must require exact capability proof. Do not imply manual or tool mutation without authorization.
  5. The final report must use a distinct state such as ALREADY_LANDED_RECONCILE_REQUIRED, not APPROVED or MERGE_BLOCKED.

Acceptance criteria

  • A PR whose head SHA is already ancestor of the target branch cannot be approved.
  • A PR whose head SHA is already ancestor of the target branch cannot trigger the merge API.
  • The workflow stops before review mutation and emits a reconciliation handoff.
  • Tests cover already-landed PR, normal mergeable PR, changed-head PR, and non-mergeable PR.
  • Final-report validation rejects APPROVED when the already-landed gate fired.
Reviewer workflows need a hard gate for PRs whose head commit is already an ancestor of the target branch. ## Observed failure A reviewer workflow processed PR #278 and validated the branch successfully. However, diagnostics showed that PR head commit `2a544b78d1371925761d16f1c451bb3b2984470e` was already present on `master`. Despite that, the workflow: * submitted an `APPROVED` review * attempted to merge PR #278 * received a Gitea API HTTP 405 merge failure * then concluded the PR was already landed and required manual reconciliation ## Problem If a PR head is already landed on the target branch, the PR is no longer a normal review/merge candidate. Approval and merge should be blocked. The workflow should enter an `ALREADY_LANDED_RECONCILE_REQUIRED` state instead. ## Required behavior 1. After selecting and pinning a PR head SHA, check whether the PR head is already an ancestor of the target branch. 2. If the PR head is already landed: * do not approve * do not request changes unless there is a real blocker * do not merge * do not attempt the merge API * produce a reconciliation handoff 3. The reconciliation handoff must include: * PR number/title * PR head SHA * target branch * proof that head SHA is already ancestor of target * linked issue status * recommended close/reconcile action * required capability checks for any close/comment/issue mutation 4. Any PR-close or issue-close action must require exact capability proof. Do not imply manual or tool mutation without authorization. 5. The final report must use a distinct state such as `ALREADY_LANDED_RECONCILE_REQUIRED`, not `APPROVED` or `MERGE_BLOCKED`. ## Acceptance criteria * A PR whose head SHA is already ancestor of the target branch cannot be approved. * A PR whose head SHA is already ancestor of the target branch cannot trigger the merge API. * The workflow stops before review mutation and emits a reconciliation handoff. * Tests cover already-landed PR, normal mergeable PR, changed-head PR, and non-mergeable PR. * Final-report validation rejects `APPROVED` when the already-landed gate fired.
jcwalker3 added the status:in-progress label 2026-07-07 04:29:57 -05:00
jcwalker3 commented 2026-07-07 04:40:00 -05:00
Author
Owner
Copy Link
Copy Source

Implementation PR opened: #368 (branch feat/issue-292-already-landed-gate, head 876f1ee).

New assess_already_landed_review_gate fail-closes approval, request-changes (unless real blocker), and the merge API when the pinned PR head is an ancestor of the target branch, returning the ALREADY_LANDED_RECONCILE_REQUIRED state plus required reconciliation-handoff fields; unchecked ancestry, bad SHAs, or a changed head block as GATE_NOT_PROVEN. Companion assess_already_landed_report_state(gate_fired=True) rejects APPROVED/MERGED/READY_TO_MERGE reports even when the report omits landed markers. 14 new tests.

Overlap: #294 requirements are covered by this gate; #295/#298 wording rules landed via #327 (PR #348). Awaiting reviewer.

Implementation PR opened: #368 (branch `feat/issue-292-already-landed-gate`, head 876f1ee). New `assess_already_landed_review_gate` fail-closes approval, request-changes (unless real blocker), and the merge API when the pinned PR head is an ancestor of the target branch, returning the `ALREADY_LANDED_RECONCILE_REQUIRED` state plus required reconciliation-handoff fields; unchecked ancestry, bad SHAs, or a changed head block as `GATE_NOT_PROVEN`. Companion `assess_already_landed_report_state(gate_fired=True)` rejects APPROVED/MERGED/READY_TO_MERGE reports even when the report omits landed markers. 14 new tests. Overlap: #294 requirements are covered by this gate; #295/#298 wording rules landed via #327 (PR #348). Awaiting reviewer.
sysadmin removed the status:in-progress label 2026-07-07 08:28:06 -05:00
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#292