e2e: TestVendorFromSubdirectory flaky — 422 non-fast-forward on scaffold push

[rh-hemartin]

Summary

TestVendorFromSubdirectory frequently fails with:

Error: installation failed: layer workflows: committing scaffold files:
  update ref: github api: 422 Update is not a fast forward

The .fullsend repo is freshly created, then scaffold files are committed via the Git Data API. When GitHub auto-initializes the repo with a default commit before the scaffold push lands, the ref update fails because it's not a fast-forward.

Affected runs

This is the most common e2e failure mode — appears in nearly every failed e2e run:

Run	Date	Branch
27939726308	2026-06-22	merge queue (PR #2481)
27936617155	2026-06-22	merge queue (PR #2457)
27936080257	2026-06-22	merge queue (PR #2475)
27934548827	2026-06-22	merge queue (PR #2457)
27823364762	2026-06-19	main

Also hits TestAdminInstallUninstall in run 27936617155.

Root cause

internal/forge/github/github.go:793 — the ref update payload only sends {"sha": "..."} without "force": true. When GitHub auto-creates a commit during repo initialization (README, license, etc.) before the scaffold push, the tree created by CommitFiles has a parent SHA that doesn't include this auto-commit, making the update non-fast-forward.

refPayload := map[string]string{
    "sha": newCommit.SHA,
}

Possible fixes

1. Set force: true on the ref update for scaffold pushes (these target a brand-new repo we own, so force is safe)
2. Create the repo with auto_init: false to prevent GitHub from creating any initial commits
3. Re-fetch the latest ref before creating the commit tree, so the scaffold commit properly parents on whatever GitHub created

Option 2 is likely the cleanest — avoids the race entirely.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 9:29 AM UTC · Completed 9:33 AM UTC
Commit: 4e21a60 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: High · Category: Bug

This is a race condition between GitHub's auto-initialization of the .fullsend repo and the scaffold file push via the Git Data API. The ref update at internal/forge/github/github.go:793 sends only {"sha": "..."} without force: true, so when GitHub creates a default commit before the scaffold push lands, the update fails with 422 Update is not a fast forward.

This is the most common e2e failure mode and is blocking PRs in the merge queue with spurious failures.

Recommended Fix

The cleanest approach is Option 2 from the issue: create the .fullsend repo with auto_init: false to eliminate the race entirely. If that's not feasible, Option 3 (re-fetch the latest ref before creating the commit tree) provides a robust fallback.

Proposed Test Case

Unit test for CommitFiles ref-update path:
- Mock the GitHub refs API to return a SHA that differs from the
  parent used when creating the commit tree (simulating auto-init race)
- Call CommitFiles with scaffold content
- Verify the code handles the non-fast-forward case gracefully
  (via force:true, ref re-fetch, or prevention of auto-init)

E2E validation:
- TestVendorFromSubdirectory already exercises this path
- A clean e2e run with zero non-fast-forward errors validates the fix

Note: issue #2490 tracks additional TestAdminInstallUninstall failure modes (401 Bad credentials, triage workflow failures) that are distinct from this race condition, though the non-fast-forward error also appears there.

---

Labels: E2e scaffold race condition bug with high impact on CI reliability — matches component/e2e, type/bug, and priority/high per repo conventions.