Migration flow races Forgejo's still-running migration: bootstrap fires early, migrator clone-loops (exit 128), repo parks unintegrated #122

New issue

Closed

opened 2026-08-13 19:08:49 +00:00 by ci-bot · 1 comment

ci-bot commented

2026-08-13 19:08:49 +00:00

Collaborator

Surfaced by the Import pane's prod E2E (www #42/#43), imp-e2e-org on 2026-08-13 — left live as a repro. Two related defects in the dispatcher's migration flow, both pre-existing (not introduced by the pane):

A. Bootstrap fires while Forgejo's migration task is still running. classifyMigration treats empty=false as content-ready, but Forgejo flips empty as soon as the first refs land, while code/issues keep importing for minutes. On imp-e2e-org/hello-world (octocat's, thousands of issues, ~6 min migration):

17:19:28 bootstrapping migrated repo repo=imp-e2e-org/hello-world
17:19:40 warn integration branch/PR setup failed; agent will improvise
         POST /branches -> 500 PushRejected "Not allowed to push to protected branch main"
17:19:41 warn run finished runId=migrator-… setupError="git clone exited 128" durationMs=218
17:19:41 warn bootstrapped repo has no prime PR and no ship signal; a bootstrap may have died mid-flight

Provisioning + the 📦 issue landed; the repo is marked bootstrapped and never retried — parked forever with no integration PR (60+ min observed). Note the branch-500 is its own sub-bug: protectMain runs before the main branch is created from master, so the branch-create is rejected by the just-applied protection.

B. A wedged Forgejo migration (empty placeholder) still gets integrated. imp-e2e-org/spoon-knife's migration starved (anonymous GitHub API quota — see below) and sat empty, yet at 17:26 the dispatcher opened integration PR #1 on it, clone-looped twice (exit 128), and handed to a validator.

Adjacent finding: tokenless migrations share the forge IP's 60/h anonymous GitHub API quota; one issue-heavy repo drains it and the next migration wedges as an empty placeholder Forgejo never cleans up.

Suggested shape: classify migrate as clone-ready only when Forgejo's migration task is finished (or probe clone-ability), retry the parked state instead of one-shot marking, and create main before protecting it.

Repro artifacts kept live: imp-e2e-org/hello-world (parked, provisioned, data issue #1). Tear down freely once diagnosed.

Surfaced by the Import pane's prod E2E (www #42/#43), `imp-e2e-org` on 2026-08-13 — **left live as a repro**. Two related defects in the dispatcher's migration flow, both pre-existing (not introduced by the pane): **A. Bootstrap fires while Forgejo's migration task is still running.** `classifyMigration` treats `empty=false` as content-ready, but Forgejo flips `empty` as soon as the first refs land, while code/issues keep importing for minutes. On `imp-e2e-org/hello-world` (octocat's, thousands of issues, ~6 min migration): ``` 17:19:28 bootstrapping migrated repo repo=imp-e2e-org/hello-world 17:19:40 warn integration branch/PR setup failed; agent will improvise POST /branches -> 500 PushRejected "Not allowed to push to protected branch main" 17:19:41 warn run finished runId=migrator-… setupError="git clone exited 128" durationMs=218 17:19:41 warn bootstrapped repo has no prime PR and no ship signal; a bootstrap may have died mid-flight ``` Provisioning + the 📦 issue landed; the repo is marked bootstrapped and never retried — parked forever with no integration PR (60+ min observed). Note the branch-500 is its own sub-bug: `protectMain` runs before the `main` branch is created from `master`, so the branch-create is rejected by the just-applied protection. **B. A wedged Forgejo migration (empty placeholder) still gets integrated.** `imp-e2e-org/spoon-knife`'s migration starved (anonymous GitHub API quota — see below) and sat empty, yet at 17:26 the dispatcher opened integration PR #1 on it, clone-looped twice (`exit 128`), and handed to a validator. **Adjacent finding:** tokenless migrations share the forge IP's 60/h anonymous GitHub API quota; one issue-heavy repo drains it and the next migration wedges as an empty placeholder Forgejo never cleans up. **Suggested shape:** classify `migrate` as clone-ready only when Forgejo's migration task is finished (or probe clone-ability), retry the parked state instead of one-shot marking, and create `main` before protecting it. Repro artifacts kept live: `imp-e2e-org/hello-world` (parked, provisioned, data issue #1). Tear down freely once diagnosed.

plat referenced this issue from a commit

2026-08-13 21:34:05 +00:00

integration waits for the migration to finish, and heals what didn't (0.33.0)

plat closed this issue

2026-08-13 22:05:32 +00:00

plat commented

2026-08-14 15:01:34 +00:00

Owner

Deep-dive addendum from the live repro: a migration task that dies AFTER git content lands (anonymous-quota exhaustion mid-issue-import) leaves repository.status=1 (BeingMigrated) forever. In that state the API git layer AND git smart-HTTP both serve normally — only the SSH serv path checks the flag and answers Internal Server Error, so integration runs can never clone while every readiness probe passes. agents 0.33.1 ships the reachable fixes (refs gate, stale-protection recovery, marker-guarded heal); the stuck-status state needs Forgejo-side healing (UPDATE repository SET status=0 once content is verified, or delete + re-migrate with a source token — the 30-min stuck note now tells users the latter). Healed the repro repo this way and integration proceeded.

Deep-dive addendum from the live repro: a migration task that dies AFTER git content lands (anonymous-quota exhaustion mid-issue-import) leaves `repository.status=1` (BeingMigrated) forever. In that state the API git layer AND git smart-HTTP both serve normally — only the SSH serv path checks the flag and answers `Internal Server Error`, so integration runs can never clone while every readiness probe passes. agents 0.33.1 ships the reachable fixes (refs gate, stale-protection recovery, marker-guarded heal); the stuck-status state needs Forgejo-side healing (`UPDATE repository SET status=0` once content is verified, or delete + re-migrate with a source token — the 30-min stuck note now tells users the latter). Healed the repro repo this way and integration proceeded.