New merge conflicts bundle issues #633

Activity

1. github-actions commented on Mar 9, 2026

   

   github-actionsBot

   on Mar 9, 2026 – with GitHub Actions

   Contributor

   More actions

   3 related issues

   • [gh-aw-upgrade] gh-aw upgrade available: v0.56.0 → v0.56.2 #628 — documents protected-file guard behavior and follow-up hardening around strict allowlisting, which could explain why this issue started after path checks were added.
   • Investigate pr merge failure #463 — analyzes a prior PR merge failure tied to patching limitations, which may provide debugging context for the failure mode reported in this issue.
   • [prompt-audit] mention-in-pr-no-sandbox drift dropped merge-conflict handling path #513 — captures a merge-conflict handling path regression in PR-assistant prompts, which may help validate whether conflict-resolution ordering is contributing here.

   ---

   What is this? | From workflow: Trigger Duplicate Issue Detector

   Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
2. github-actions commented on Mar 9, 2026

   

   github-actionsBot

   on Mar 9, 2026 – with GitHub Actions

   Contributor

   More actions

   tl;dr: this looks like a real incompatibility introduced by recent changes — the merge-conflict flow now recommends merge-based updates, but push_to_pull_request_branch blocks any .github/** changes, so merge bundles that include upstream workflow updates are rejected.

   1) Recommendation

   Use protected-files: fallback-to-issue for push-to-pull-request-branch in the merge-conflict/update-branch path (or split merge-bundle generation to exclude upstream-only .github/** changes before push). I recommend the fallback route first because it preserves protection while avoiding hard failure.

   2) Findings

   • Protected path guard is active for push-to-PR:
     • .github/workflows/gh-aw-fragments/safe-output-push-to-pr.md:147-150
   • Same fragment now explicitly instructs merge-based conflict resolution:
     • .github/workflows/gh-aw-fragments/safe-output-push-to-pr.md:164-169
   • Compiled lock workflow includes both instructions and protected path enforcement:
     • merge guidance: .github/workflows/gh-aw-mention-in-pr.lock.yml:455-460
     • handler config with "protected_path_prefixes":[".github/",".agents/"]: .github/workflows/gh-aw-mention-in-pr.lock.yml:1938
   • Related recent PRs:
     • #599 added protected-files guards for .github/**
     • #600 introduced/expanded merge-based update-branch guidance
   • I did not find a prior issue in this repo specifically tracking this exact regression (searches for protected-files + merge conflict only surfaced #633).

   3) Verification

   I ran targeted checks locally:

   # Repro: merge-from-base can introduce protected workflow file into bundle diff
   # (simulated PR head -> merge base into feature -> diff from original PR head)
   $ git diff --name-only "$pr_head"..HEAD
   .github/workflows/ci.yml

   # Relevant guard tests
   $ /tmp/gh-aw/agent/triage-venv/bin/python -m pytest tests/test_safe_input_ready_to_make_pr.py -q
   ................................                                         [100%]
   32 passed in 2.28s

   Notes:

   • Existing tests validate merge/history-rewrite behavior (tests/test_safe_input_ready_to_make_pr.py:496-557), but there is no explicit test combining merge-bundle behavior with protected .github/** content.

   4) Detailed Action Plan

   1. Adjust push behavior for protected files during merge-conflict flows
      • File: .github/workflows/gh-aw-fragments/safe-output-push-to-pr.md
      • Around lines 147-152, change protected-files handling to fallback issue mode (rather than hard-fail).
   2. Keep merge guidance and push guard aligned
      • File: .github/workflows/gh-aw-fragments/safe-output-push-to-pr.md
      • Ensure lines 164-169 (merge guidance) do not conflict with runtime enforcement semantics.
   3. Recompile workflow lock files
      • Regenerate .lock.yml workflows so the updated safe-output config propagates.
   4. Add regression coverage
      • File: tests/test_safe_input_ready_to_make_pr.py
      • Add a test case that simulates: original PR head -> base changes .github/workflows/* -> merge base into PR branch -> assert intended outcome (fallback issue path or explicit error contract).
   5. Validate
      • Run the existing test target for ready_to_push_to_pr guards and workflow lint/compile checks used by the repo.

   5) Related Items

   Type	Link	Relevance
   Issue	#633	Current report
   PR	#599	Introduced .github/** protected-files guardrails
   PR	#600	Introduced merge-based update-branch guidance
   File	.github/workflows/gh-aw-fragments/safe-output-push-to-pr.md:147-150	Protected-files config
   File	.github/workflows/gh-aw-fragments/safe-output-push-to-pr.md:164-169	Merge-conflict guidance
   File	.github/workflows/gh-aw-mention-in-pr.lock.yml:1938	Compiled protected path prefixes
   File	tests/test_safe_input_ready_to_make_pr.py:496-557	Existing merge/history tests

   ---

   What is this? | From workflow: Trigger Issue Triage

   Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
3. strawgate commented on Mar 9, 2026

   

   strawgate

   on Mar 9, 2026

   ContributorAuthor

   More actions

   /ai I was kinda hoping that it was getting confused by the merge bundle, the agent that made the merge bundle never actually modified workflow files so I'm wondering if there's something else going on here, can you explore the gh-aw code base and that agents run log and figure out where happening

   👀React with 👀1Reacted by github-actions
4. github-actions commented on Mar 9, 2026

   

   github-actionsBot

   on Mar 9, 2026 – with GitHub Actions

   Contributor

   More actions

   You were right to suspect the merge bundle path — the run log shows the failure is happening in safe-outputs validation, and the generated patch actually contains real .github/workflows/* changes (not just a false detector hit).

   Evidence from the run artifacts/logs:

   • Safe outputs rejected message 1 while processing push_to_pull_request_branch because the patch modified protected workflow paths (/tmp/gh-aw/agent/safe_outputs_job.log:728-734).
   • The ingested output explicitly says this was a merge flow: "message":"merge: resolve conflicts with origin/main" (/tmp/gh-aw/agent/agent_job_full.log:2115).
   • The generated patch (aw-copilot-unify-error-alert-scaffolding.patch) is a 30-commit bundle and includes multiple workflow commits, e.g. [PATCH 03/30] touches .github/workflows/ci.yml, ui-smoke-test-main.yml, ui-smoke-test-pr-review.yml (...patch:170-179, :181+).
   • That same patch also includes upstream main commit 852e24a as [PATCH 24/30] (...patch:3719-3723), confirming base-branch commits were swept into the outgoing bundle.

   So the core issue is not that safe-outputs is misclassifying unchanged files; it is that the merge-based conflict resolution produced a patch range that pulled in upstream commits (including workflow edits), and protected-path enforcement then correctly blocked push.

   Likely fix direction:

   1. For push_to_pull_request_branch, avoid merge-commit conflict resolution (git merge origin/main) and use single-parent/manual conflict application only.
   2. If merge-based flow is retained, set protected-files behavior to fallback issue for this path (so it degrades gracefully instead of hard failing).
   3. Add a pre-push guard that inspects the generated patch file list and fails early with explicit guidance before calling safe-outputs push.

   ---

   What is this? | From workflow: Trigger Mention in Issue

   Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
5. strawgate commented on Mar 9, 2026

   

   strawgate

   on Mar 9, 2026

   ContributorAuthor

   More actions

   /ai so a GitHub workflow using the workflow token can't push a change to workflows even in a merge commit? How sure are you?

   👀React with 👀1Reacted by github-actions
6. github-actions commented on Mar 9, 2026

   

   github-actionsBot

   on Mar 9, 2026 – with GitHub Actions

   Contributor

   More actions

   Short answer: for this failure, I’m highly confident (~95%+) it was blocked by our own safe-output guardrails, not by GitHub refusing merge-commit pushes in general.

   Evidence in repo:

   • .github/workflows/gh-aw-fragments/safe-output-push-to-pr.md:148-150 explicitly sets protected-files: [".github/**"] for push-to-pull-request-branch.
   • The compiled workflow carries that into runtime config as "protected_path_prefixes":[".github/",".agents/"] at .github/workflows/gh-aw-mention-in-pr.lock.yml:1938.
   • Merge commits are currently intended to be allowed by guidance (.github/workflows/gh-aw-fragments/safe-output-push-to-pr.md:164-169) and test coverage (tests/test_safe_input_ready_to_make_pr.py:496-515), so “merge commit” does not bypass the protected-files check.

   So the practical behavior today is: if the outgoing patch includes .github/** (even if that came from a merge bundle), push_to_pull_request_branch is expected to reject it.

   ---

   What is this? | From workflow: Trigger Mention in Issue

   Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
7. strawgate

   assigned

   Copilot

   and

   strawgate

   on Mar 9, 2026
8. strawgate

   closed this as completedin #637on Mar 9, 2026