AntFleet

Disagreement · 0a8afccf-openai-2

Merge failure paths assume a conflicted merge state; certain failures (e.g., unrelated histories) produce no changes, leading to misleading "conflicts" PR body

mismatch
repo 6f7fc663·PR #17·reviewed 1 week ago

Primary finding

Merge failure paths assume a conflicted merge state; certain failures (e.g., unrelated histories) produce no changes, leading to misleading "conflicts" PR body

mediumbugmedium
  • .github/workflows/sync-upstream.yml:54-61
  • .github/workflows/sync-upstream.yml:77-80
The else-branch assumes any merge failure leaves a merge state with conflicted files that can be staged and committed with markers. However, some failures (e.g., `fatal: refusing to merge unrelated histories`) abort without creating a merge state. In that case, `git add -A` has nothing to stage and `git commit` fails (suppressed by `|| true`), resulting in no changes pushed while the PR body still claims conflict markers were committed. This yields misleading PRs and hides the underlying merge failure mode.

Recommendation

Detect merge failure modes where no merge state is produced (e.g., check for `.git/MERGE_HEAD` existence or `git status --porcelain` after the failed merge). If no merge state exists, either stop the workflow with a clear error message or perform an `--allow-unrelated-histories` merge when appropriate. Update the PR body accordingly only when conflict markers were actually committed.

Counterpart finding

Sync workflow cannot push branch or open PR due to default GITHUB_TOKEN permissions on protected default branch / branch policies, and creates a new branch every run on the same day produces stale branches

lowbuild-releaselow
  • .github/workflows/sync-upstream.yml:62-66
Branch name is keyed by date only. If the workflow runs twice in one day (e.g. manual dispatch after the scheduled run), the second invocation will `git checkout -b` an already-existing remote branch locally fresh, then `git push` will succeed only if the local branch is a fast-forward of the remote. After a force-push amend by a human reviewer, a subsequent same-day automated run would fail to push (non-fast-forward) and leave the PR un-updated. Across days, the workflow opens a brand-new PR each week, accumulating stale PRs instead of updating one. The script does call `gh pr edit` if a PR with the same head exists, but since the head branch changes daily, that path is only hit within the same UTC day.

Recommendation

Either reuse a stable branch name (e.g. `sync/upstream`) and force-push, or detect existing same-named branch and reset it. Also consider closing prior open sync PRs when opening a new one.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →
← back to all disagreementsview public receiptssee unanimous findings + anatomies →
Tweet ↗