reconcile-repos.sh: branch reset auto-closes enrollment PRs

[ascerra]

What happens

ensure_branch() in reconcile-repos.sh force-resets the fullsend/onboard branch to the default branch tip before writing the updated shim. During the reset the branch momentarily has zero diff from main, causing GitHub to auto-close the existing enrollment PR. The subsequent write_shim_to_branch() pushes new content (branch is 1 commit ahead again), but GitHub does not reopen auto-closed PRs.

The script's gh pr list check then sees no open PR and may or may not successfully create a replacement, depending on timing and error handling.

What should happen

The branch update should avoid the zero-diff state. Options:

• Write the updated shim content in the same commit as the branch reset (atomic update)
• Detect and gh pr reopen auto-closed PRs after the push
• Use git commit --amend or rebase instead of resetting to base then re-committing

Context

Observed during the v0.5.0 upgrade of fullsend-ai. The experiments enrollment PR (fullsend-ai/experiments#18) survived because its shim content differed enough to avoid the zero-diff window, but the fullsend enrollment PR (fullsend-ai/fullsend#696) was auto-closed and had to be manually reopened.

Related

• reconcile-repos.sh: enrollment check compares file existence, not content #348 — enrollment check compares file existence, not content
• Reconciliation script PRs should use conventional commit prefix #385 — reconciliation PR title format

[fullsend-ai-triage]

RICE Priority Score: 2.7

Score breakdown

Dimension	Score	Reasoning
Reach	2	This bug affects the enrollment/reconciliation flow which every onboarding org passes through. All three strategic customers (konflux-ci, openkaiden, guacsec) will hit this during onboarding or version upgrades. It was already observed on the fullsend-ai org itself during v0.5.0 upgrade, and konflux-ci is expected to onboard dozens more repos in May 2026.
Impact	1.5	The bug silently auto-closes enrollment PRs, breaking the automated onboarding workflow and requiring manual intervention to reopen. This is a significant pain point — it degrades trust in the platform's automation and creates friction during a critical first-impression moment (onboarding), but it does not cause data loss and has a manual workaround (reopening the PR).
Confidence	0.9	Very high confidence. The issue is precisely described with exact code references, a clear reproduction scenario (v0.5.0 upgrade), specific PRs that were affected, and multiple proposed solutions. The root cause (GitHub auto-closing PRs on zero-diff) is well-understood.
Effort	1	Medium complexity. The fix is scoped to a single script (reconcile-repos.sh) and the author has proposed three clear solution paths. The main work is choosing the right approach (atomic update vs. reopen detection vs. amend) and testing the race condition is resolved. Touches one file but requires careful handling of git/GitHub edge cases.

Formula: (2 × 1.5 × 0.9) / 1 = 2.7