search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
43.02k stars 5.31k forks source link

`FindRecentlyPushedNewBranches` finding non-existing Branches #31471

Open theAkito opened 1 week ago

theAkito commented 1 week ago

Description

Follow up on #31163. This issue has been worked around in the mentioned issue and this issue is for solving the root problem.

The issue starts to appear, when you upgrade from a pre-1.22 version to the 1.22 version.

The problem displayed itself as the user trying to open a repository and then hitting a HTTP 500 Error, because the system tries to find the default branch named main. Right now, this error is not displayed in the Nightly version of 1.22, because it is just hidden and ignored. The root issue remains unsolved.

I use this space to clarify and further detail the description of the root problem.

This comment by a maintainer suggests, that when a default branch by the default name is missing, the branch might've been deleted, renamed or a default branch might simply not be set, which happened between the upgrade from an older version to 1.22, before the workaround was released.

I can 100% confirm, that this is not the case. My repositories worked for all previous versions, then I switched to 1.22 and suddenly the system looks for a branch, that never existed in any of the repositories on my instance in the first place. No default branches have been ever re-assigned or even deleted.

The root problem is related to the system trying to find the default branch main, even though, there is no reason for looking for it. Even, if it has never been there. It still looks for it. This is one question, that needs to be answered, to be able to properly fix the issue.

I welcome other affected users to comment on this issue and add further information for clarifying the issue at hand.

Gitea Version

1.22-nightly

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Kubernetes via Helm

(Happens on any type of deployment, though.)

Database

PostgreSQL

CHN-STUDENT commented 1 week ago

I get same issue when i update 1.21.4 to 1.22.0 Release not nightly，when i push some project code to my gitea origin, i get FindRecentlyPushedNewBranches Error, i do not know how to fix it or downgrad gitea my gitea origin now seems work wrong.

image image

@wxiaoguang @lunny please help me thanks!

theAkito commented 1 week ago

I get same issue when i update 1.21.4 to 1.22.0 Release not nightly，when i push some project code to my gitea origin, i get FindRecentlyPushedNewBranches Error, i do not know how to fix it or downgrad gitea my gitea origin now seems work wrong.

image image

@wxiaoguang @lunny please help me thanks!

Thanks for the information.

Did you check out how to apply the workaround, to make this error disappear? It works for me.

https://github.com/go-gitea/gitea/issues/31163#issuecomment-2180559370

If you have specific questions regarding the setup, perhaps you could ask on the forum for clarification. I would be happy to help.

CHN-STUDENT commented 1 week ago

oh i need to upgrade 1.22-nightly to try?

UPDATE: Yeah, i download then upgrade, now seems it's work correctlly. Thanks! i hope they fixed it by lastest version as soon as quicky and tell every person who meet this issue.

Thanks for your help.

wxiaoguang commented 1 week ago

This comment by a maintainer suggests, that when a default branch by the default name is missing

That's only one case for the "branch sync" problem .....

I can 100% confirm, that this is not the case. My repositories worked for all previous versions, then I switched to 1.22 and suddenly the system looks for a branch, that never existed in any of the repositories on my instance in the first place. No default branches have been ever re-assigned or even deleted.

That's another case: some branches are out-of-sync for some known or unknown reasons, so "sync branches" on the admin dashboard panel could also "fix" the problem.

The root problem is the "branch sync mechanism", it is incomplete in some cases (but at the moment I can't tell more .....), the cases need to be fixed one by one.

theAkito commented 1 week ago

This comment by a maintainer suggests, that when a default branch by the default name is missing

That's only one case .....

I can 100% confirm, that this is not the case. My repositories worked for all previous versions, then I switched to 1.22 and suddenly the system looks for a branch, that never existed in any of the repositories on my instance in the first place. No default branches have been ever re-assigned or even deleted.

That's another case: some branches are out-of-sync for some known or unknown reasons, so "sync branches" on the admin dashboard panel could also "fix" the problem.

The root problem is the "branch sync mechanism", it is incomplete in some cases (but at the moment I can't tell more .....), the cases need to be fixed one by one.

I see. Thanks for the clarification.

However, even if it is out of sync, why does it search for a main branch? The reason I'm asking is, is because it's so random and shows, that the branches of the particular repository were not even screened, at all.

wxiaoguang commented 1 week ago

However, even if it is out of sync, why does it search for a main branch?

Because if a repo doesn't have a default branch, but the database might have recorded "main" as the default branch.

There could be some different causes:

  1. the repo itself doesn't really have a default branch, but database recorded value is "default_branch=main"
  2. the repo itself ever had a default branch, but the branch was renamed or deleted but the database record doesn't get update (just my guess)
  3. the repo itself ever had correct branches, but the database branches were not updated (and corrupted) due to some reasons then the branches recorded in database are out-of-sync of the real git branches (still just my guess)

More context: theoretically, the "branch list" should be correctly stored in a database table and used from that database table, the "default branch" is also stored in database. In most cases, the "branch list" and "default branch" in database should be the same as what in a git repo. However, sometimes "branch list" and "default branch" might differ from from the underlying git repo (surely it is a bug). Even the underlying repo doesn't really have a default branch, "default branch" could also be something like "main".