mirror of
https://github.com/RayLabsHQ/gitea-mirror.git
synced 2026-05-23 08:01:19 -05:00
[GH-ISSUE #268] Imported repositories stuck at mirroring state #2509
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/gitea-mirror#2509
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?
Originally created by @iqfareez on GitHub (Apr 14, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/268
Originally assigned to: @arunavo4 on GitHub.
I couldn't found existing issue that relates to my problem so I'm creating one.
While most of the imported repositories being mirrored successfully. There still a bunch left in the "Mirroring" state. I waited hours and it still in the mirroring state. I don't know what causes them to not actually mirroring to gitea. Clicking the gitea link button on the right showing Page not found.
There is no job pending in Activity Logs either. What have I tried:
But neiter solves the mirroing issues. So, how do I make gitea-mirror continue to actually mirror to gitea? Thanks to all!
@arunavo4 commented on GitHub (Apr 15, 2026):
@iqfareez please drop the logs
@rijndael86 commented on GitHub (May 1, 2026):
this is also happening to me, I've been stuck with 191 mirroring repos for many days now, out of 347
@arunavo4 commented on GitHub (May 2, 2026):
@rijndael86 please drop some logs that would help narrow the issue
@elpastorios commented on GitHub (May 3, 2026):
To add to this, I "think" I am experiencing the same issue. I was on v3.15 when first installed and just updated to v3.15.6 but the issue persists. When I am stuck at the mirroring state, for some reason multiple reps are created in gitea for the same rep.
gitea-mirror-logs.txt
@arunavo4 commented on GitHub (May 4, 2026):
Released v3.15.7 with a fix. Quick heads up on what it does and doesn't cover.
The actual bug was a JS scoping issue in the catch block. When the Gitea migrate call timed out or hit any other error, the catch tried to read a variable that didn't exist in its scope, threw a ReferenceError, and never got around to updating the repo to "failed" in the database. That's why everything sat silently in "mirroring" with no entry in Activity Logs.
After upgrading:
@iqfareez and @rijndael86, your existing stuck repos will move to "failed" on the next retry attempt, or automatically once they cross the 2 hour stale window. Once they fail, the activity log will show the real underlying error (timeout, auth, rate limit, whatever it actually is). Please retry after upgrading and post the new error message here. That's the part we can't see right now and it's what we need to diagnose your specific case.
@elpastorios, the same-repo-multiple-times pattern in your screenshot is a separate issue. What's happening is that Gitea finishes the migration in the background even after our HTTP client times out, so an orphan repo gets left behind. On retry, the unique name logic finds that orphan and adds
-1,-2suffixes. To unstick: delete the orphan repos in Gitea manually, then retry. The orphan detection fix is on the follow-up list.