Handle post-approval merge conflicts without dropping the automation loop#12
Merged
Handle post-approval merge conflicts without dropping the automation loop#12
Conversation
…loop When a final APPROVE verdict hits a GitHub merge conflict, dani now queues a dedicated merge conflict resolution OMX session instead of stopping at the failed merge. That resolver updates the PR branch from the base branch, asks the agent to re-verify the result, and posts a signed PR comment so the normal webhook flow can trigger a fresh final verdict before merging again.\n\nThe implementation keeps the existing queue/signature/webhook design intact by adding only one new stage and reusing the same PR-comment handshake already used for review rounds. GitHub merge conflict detection is isolated in the PyGithub wrapper so the service can treat 409 conflicts as workflow state instead of a generic failure.\n\nConstraint: Must preserve the existing repo-serial queue and signed webhook flow\nConstraint: Merge conflicts must trigger re-verification before the PR is merged\nRejected: Auto-merge again immediately after a failed merge | would skip the required re-review after conflict resolution\nRejected: Resolve conflicts inline inside the webhook handler | would block the handler and bypass the OMX session model\nConfidence: high\nScope-risk: moderate\nReversibility: clean\nDirective: Keep merge-conflict resolution as a signed workflow stage so verdict retries remain event-driven\nTested: uv run pytest -q; uv run ruff check; uv run ty check\nNot-tested: Live GitHub API merge-conflict recovery against a real conflicted PR
Merged current origin/main so this branch picks up the omx exec/resume runtime, dev-sync flow, and exact-signature verification while preserving the post-approval merge-conflict-resolution loop. The service and tests now keep live PR metadata when rerunning final verdict after a conflict, so the resumed review path stays grounded in the current PR state instead of the resolution comment body. Constraint: origin/main already changed the runtime/session model from tmux madmax launches to omx exec plus resumable issue sessions Rejected: Rebuild the branch on the stale pre-merge main snapshot | would drop behavior now shipped on main Confidence: high Scope-risk: broad Directive: Keep merge-conflict retry logic aligned with the latest PR snapshot and the exact-signature verification model Tested: make check; make test; make build Not-tested: Live GitHub webhook to OMX runtime flow against a real merge-conflict PR
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #11
Summary
merge_conflict_resolutionstage when a finalAPPROVEmerge fails becausedevmoved aheadfinal_verdictmainchanges into this branch so the new flow works with the currentomx exec/ resume runtime and exact-signature verification modelVerification
make checkmake testmake build