Error - FindRecentlyPushedNewBranches, branch does not exist [repo_id: 64 name: main]

[Flagelmann]

Description

I'm getting a weird issue on several repositories.

The actual error is a 500 error:

FindRecentlyPushedNewBranches, branch does not exist [repo_id: 64 name: main]

How to solve this? Should I modify the branch name directly on DB side? Is there any way to fix this from the Gitea web portal?

Actually, it seems that this new version has broken several repos at once. Until last week everything was good, clean and accessible. Now I'm getting this error on several repositories.

Gitea Version

1.22.0

Workaround

It has been fixed in 1.22-nightly (which will be 1.22.1 soon), please use the 1.22-nighly binary (https://dl.gitea.com/gitea/1.22-nightly/) or docker image.

[lunny]

Please try to run sync branches on admin panel.

[Flagelmann]

Yout mean the "Resynchronize pre-receive, update and post-receive hooks of all repositories."?

I have already tried multiple times it....nothing changed.

I also tried "Reinitialize all missing Git repositories for which records exist" under "Site Administration", nothing even with this.

I wish I will not have to rebuild the gitea instance from scratch.....so, re-import manually over 100 repositories (over 30 GB of data) and then also re-enable manually, by modifying manually each repository on database side the mirroring settings for each repo I have (as Gitea does not still have the way to backup these settings)....

[wxiaoguang]

Please try to run sync branches on admin panel.

I do not think FindRecentlyPushedNewBranches logic is right. Anything wrong in that function shouldn't block end users seeing a complete page.

[lunny]

Yout mean the "Resynchronize pre-receive, update and post-receive hooks of all repositories."?

I have already tried multiple times it....nothing changed.

I also tried "Reinitialize all missing Git repositories for which records exist" under "Site Administration", nothing even with this.

I wish I will not have to rebuild the gitea instance from scratch.....so, re-import manually over 100 repositories (over 30 GB of data) and then also re-enable manually, by modifying manually each repository on database side the mirroring settings for each repo I have (as Gitea does not still have the way to backup these settings)....

No. It's Sync missed branches from git data to databases

[Flagelmann]

I get, not for all repositories (fortunately), a Gitea error page with a big "500" at center page and then, just below, the message:

An error occurred:

FindRecentlyPushedNewBranches, branch does not exist [repo_id: 64 name: main]

Nothing else.

[Flagelmann]

Even with "Sync missed branches from git data to databases" nothing changed. It starts, but then nothing...

[lunny]

I get, not for all repositories (fortunately), a Gitea error page with a big "500" at center page and then, just below, the message:

An error occurred:

FindRecentlyPushedNewBranches, branch does not exist [repo_id: 64 name: main]

Nothing else.

The sync will take some times, maybe you need to wait for a while and refresh the page again.

[wxiaoguang]

As a quick fix: Ignore FindRecentlyPushedNewBranches err #31164

If you could build your own instance, you could try to apply it to 1.22 branch.

Or when the backport is done and 1.22-nightly is ready, please try 1.22 nightly.

[Flagelmann]

I am using snapcraft to deploy and get updates of Gitea.

May I get the nightly build with snap or do I have just to wait the next build?

[yp05327]

As a quick fix it is ok, but I think the root reason is that sync branch has some problems.
The branch name is main, so it is default branch of repo 64?
Then what kind of this repo is? A fork, a mirror or a normal one?
Then why this branch can not be found in DB? During the creation of this repo, the main branch should has been insert into the DB.

[wxiaoguang]

Reopen, because the quick fix isn't complete. Need to figure out the root reason.

[wxiaoguang]

The root problem is that any branch could be renamed or deleted. Default branch may not exist in many cases.

So when running FindRecentlyPushedNewBranches, any non-existing branch should be ignored, but not reporting an error.

[yp05327]

I can only image one case that the last branch (it is also the default branch) was deleted, and there's no branch in the repo, this error would happen.
If the default branch is renamed, repo.DefaultBranch should also be renamed?
If there's two or more branches, then when the default branch was deleted, the other one will be the new default branch?

[Flagelmann]

Jfyi, I have fixed the issue by issuing a simple UPDATE query against the specific repository ID in the repository table, updating the default_branch value from "main" to "master". Just after doing that now I can access the affected repository.

I will have to check all of them one by one, as not all repository are using the "master" branch, some are using "main".

Here a sample query I used:

UPDATE repository SET default_branch = 'master' WHERE id = 100;

Finally, I dunno why this happened, as just before the upgrade to the latest build I was able to use the affected repositories without issues (and they were on master branch, not main, and I checked it in the commit history); after the upgrade several repositories have been "moved" to the main branch without a reason.

Wishing that this will not happen anymore in the next builds.

Regards

[lunny]

Maybe the algorithm of detection defulat branch when syncing branches into database are wrong. So that, all repositories with master as default branch but your default branch in app.ini is main will be wrong.

[Flagelmann]

Probably, for now I have reverted manually, as it was the only way to fix this without disruptions, each repository affected from the wrong default branch to the correct one (master, most of the times).

But now I'm a bit worried about next builds/updates. :D

[lunny]

Probably, for now I have reverted manually, as it was the only way to fix this without disruptions, each repository affected from the wrong default branch to the correct one (master, most of the times).

But now I'm a bit worried about next builds/updates. :D

You don't need to worry about next update. Syncing branches to database is a new infrastructure refactor of 1.22. It should only do increment sync after the first sync for every repository.

Can you confirm only repositories with default branch master were affected?

[Flagelmann]

No, actually there was even another repository that was not on master (still figuring out which was the previous one) but it was put on main also.

UPDATE: ok, the other repository was on "dev" as default branch name but it was also put to "main". Now reverted and I can access it again.

[spiritLHLS]

Jfyi, I have fixed the issue by issuing a simple UPDATE query against the specific repository ID in the repository table, updating the default_branch value from "main" to "master". Just after doing that now I can access the affected repository.

I will have to check all of them one by one, as not all repository are using the "master" branch, some are using "main".

Here a sample query I used:

UPDATE repository SET default_branch = 'master' WHERE id = 100;

Finally, I dunno why this happened, as just before the upgrade to the latest build I was able to use the affected repositories without issues (and they were on master branch, not main, and I checked it in the commit history); after the upgrade several repositories have been "moved" to the main branch without a reason.

Wishing that this will not happen anymore in the next builds.

Regards

I'm having the same problem, hopefully the next new release fixes this and does it automatically (since my gitea is mainly used for backups, there are too many affected repositories for me to have the time to detect and manually fix them all).

[Flagelmann]

Well, I checked the 180+ repositories I have right now on my Gitea instance and I would say that 1/3 of them have been affected by this issue. Now I have fixed them, but obviously I will monitor after next update if this will happen again.

[eeyrjmr]

This is what I faced as well, luckily only one ...
In my case it was something a little bit low-level such that the one repo facing this appeared to have two origin/master and even cli got had a warning (gitea just 500 on the code page as it didn't have a default)

[Flagelmann]

I did not know about the /issue URL part. Good to know.

Probably this is just a Gitea-side issue as I checked, in my case, and the git repos were still there untouched, but not visible.

Actually in my case it was much quicker to identify which was the wrong value on DB side and update it directly for all the affected repo IDs.

[Cat7373]

I also encountered this problem, after upgrading to 1.22.0

[wxiaoguang]

I also encountered this problem, after upgrading to 1.22.0

Please try 1.22-nightly , and/or try to "Sync branches" from the admin dashboard panel

[yp05327]

Maybe this is caused by auto renaming branch name
After the renaming, the branch name in DB is not changed

But this could be fixed by sync branches. 🤔
After I sync branches, it worked.

[yp05327]

Does this related to #28056 ?
User didn't notice this issue, so branches are not synced since updated to v1.21, and errors occurred after upgrade to v1.22?

[Flagelmann]

Actually in my case it was not due to an auto-renaming of the branches, as I had, suddenly after the auto-upgrade (using snap image) 40-50 repositories not usable anymore using Gitea, then I fixed each of them directly in DB and after the value updated on DB side I did just an F5 on the page of the affected repo and it turned back working as expected.

Also, on #28056 the error was about LoadBranches while in this case I got FindRecentlyPushedNewBranches.

Obviously I tried several times the "Sync Branches" but it was completely useless (nothing fixed with that function).

[theAkito]

100% agree with OP. Same experience here.

[wxiaoguang]

100% agree with OP. Same experience here.

It has been fixed in 1.22-nightly (which will be 1.22.1 soon), please use the 1.22-nighly binary (https://dl.gitea.com/gitea/1.22-nightly/) or docker image.

[theAkito]

100% agree with OP. Same experience here.

It has been fixed in 1.22-nightly (which will be 1.22.1 soon), please use the 1.22-nighly binary (https://dl.gitea.com/gitea/1.22-nightly/) or docker image.

Ah, I see, I thought it would be backported into the 1.22 branch.

Is this Nightly release production ready or would it be rather advisable to wait for 1.22.1?

Is there a release date for 1.22.1?

[wxiaoguang]

Ah, I see, I thought it would be backported into the 1.22 branch.

Yes, it has been backported to 1.22, so 1.22-nightly contains it.

Is this Nightly release production ready or would it be rather advisable to wait for 1.22.1?

Yes, because 1.22-nighty will be 1.22.1 soon. It is exactly for production so no need to wait.

Is there a release date for 1.22.1?

Maybe in a several days.

[theAkito]

@wxiaoguang

Which branch or commit do I need to check out from Git to get exactly the state of 1.22-nightly? I want to build my own Docker image.

[delvh]

release/1.22

[delvh]

(± one day as nightly is probably built only once a day as the name implies)

[theAkito]

Nice, seems to work now and the issue is worked around. Thank you!

[delvh]

The issue seems to be fixed.

[yp05327]

The root reason is not fixed.
We have some unknown issues about sync branch to DB.

[theAkito]

@yp05327 I agree.

I even specifically said

the issue is worked around

because it is not fixed. 😄

[wxiaoguang]

I believe the root problem needs a new issue to clarify the details, but not keeping discussing "FindRecentlyPushedNewBranches" here .....

The FindRecentlyPushedNewBranches bug is indeed fixed, it sounds like a workaround but the approach is right: to make the system robust. No matter there is the root problem or not, the fix is still right and necessary.

(And see my comment above: #31163 (comment) the default branch may not exist in some cases)

[lunny]

Let's open a new issue.

[theAkito]

Let's open a new issue.

Which is it? I don't see a related new issue in the list.

I'll create a new one, then.

Here it is.

[amirad1]

It seems in the 1.22.1 version, the 500 error is fixed but I still get the error log ? should I ignore it or not ?

[lunny]

It seems in the 1.22.1 version, the 500 error is fixed but I still get the error log ? should I ignore it or not ?

Please open a new issue and paste your error logs.

[wxiaoguang]

@lunny you have asked so above #31163 (comment) and there is already one #31163 (comment) : #31471