AntFleet

Disagreement · 0a8afccf-openai-1

Reusing date-based branch name can cause non-fast-forward push failures if an existing sync branch diverged

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

Primary finding

Reusing date-based branch name can cause non-fast-forward push failures if an existing sync branch diverged

mediummaintainabilitymedium
  • .github/workflows/sync-upstream.yml:51-53
  • .github/workflows/sync-upstream.yml:64-66
The branch name is reused for all runs on the same day. If a previous run opened a PR and maintainers (or CI) pushed additional commits to that branch, the next run creates a fresh local branch and attempts a non-forced push, which will fail with a non-fast-forward error. The workflow does not detect or handle this case, leading to intermittent failures and stale PRs.

Recommendation

Before creating the branch, check if the remote branch exists and base the local branch on it (e.g., `git fetch origin "$BRANCH" || true` and `git checkout -B "$BRANCH" origin/"$BRANCH"`), then merge upstream and push. Alternatively, make the branch name unique per run (include timestamp or upstream commit hash) and rely on PR auto-update using `gh pr create --fill --head "$BRANCH"` accordingly.

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 ↗