mirror of
https://github.com/RayLabsHQ/gitea-mirror.git
synced 2026-05-23 16:11:17 -05:00
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/RayLabsHQ/gitea-mirror/pull/280
Author: @arunavo4
Created: 5/3/2026
Status: ✅ Merged
Merged: 5/4/2026
Merged by: @arunavo4
Base:
main← Head:fix/issue-268-stuck-mirroring📝 Commits (2)
4351f4efix: hoist migrateSucceeded above try so catch can update DB on failure (fixes #268)bf0a2cdtest: replace integration test with structural source check (#268)📊 Changes
2 files changed (+140 additions, -6 deletions)
View changed files
➕
src/lib/gitea-mirror-failure-recovery.test.ts(+132 -0)📝
src/lib/gitea.ts(+8 -6)📄 Description
Summary
mirroringstate after transient network errors, with no failure entry in the activity loglet migrateSucceededabove thetryblock inmirrorGithubRepoToGiteaandmirrorGitHubRepoToGiteaOrgso thecatchblock can actually read itRoot cause
let migrateSucceeded = false;was declared inside thetryblock.letis block-scoped, so thecatchblock at the bottom of the same function couldn't see it. When any operation insidetrythrew (timeout to Gitea, 4xx/5xx, etc.), the catch block crashed withReferenceError: migrateSucceeded is not definedbefore it could:status: "failed"mirroredLocation"failed"activity-log entrySo the repo was permanently stuck in
mirroring, no failure log appeared, and the user-visible error on retry was the misleadingFailed to mirror repository: migrateSucceeded is not definedinstead of the real cause.This was visible in elpastorios's logs on the issue:
The first line is the catch's
console.error(runs before the bad reference); the second is the wrapper frommirrorGitHubOrgRepoToGiteaOrg's outer catch atgitea.ts:1857.TypeScript was already flagging
Cannot find name 'migrateSucceeded'at the catch lines — but esbuild strips types during build, so the bug shipped.Introduced in #236.
What this fix does NOT cover
The trigger — Gitea's
/repos/migratetiming out client-side while continuing in the background — still leaves orphan repos that retries see and rename torepo-1,repo-2(the duplicates in elpastorios's screenshot). That's a separate fix; options include probing Gitea after a timeout, raising the migrate timeout, or makinggenerateUniqueRepoNameaware of orphans owned by this user. Worth following up on but out of scope here — this PR stops the bleeding so transient errors no longer leave repos permanently stuck.Test plan
src/lib/gitea-mirror-failure-recovery.test.tscover bothmirrorGithubRepoToGiteaandmirrorGitHubRepoToGiteaOrg. They forcehttpPostto reject and assert:migrateSucceeded is not defined)status: "failed"andmirroredLocation: ""createMirrorJobis called withstatus: "failed"Received: "migrateSucceeded is not defined"— exact production errorbun test— 233 pass, 0 fail across 39 filesfailedand a failure entry appears in Activity Logs🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.