github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-15 20:09:18 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

500 Error On Release Page #4106

New Issue
Closed
opened 2025-11-02 05:38:10 -06:00 by GiteaMirror · 25 comments
GiteaMirror commented 2025-11-02 05:38:10 -06:00
Owner
Copy Link

Originally created by @carc1n0gen on GitHub (Oct 12, 2019).

Description

I created a repo on my gitea instance, added as a remote on an existing repo, and pushed. That was fine. I then noticed the releases page was empty since I hadn't pushed the tags. So I pushed the tags. Now the releases page yields a 500 error page.

The repo is public, so here it is: https://gitea.carsonevans.ca/carson/quickpaste/releases

Originally created by @carc1n0gen on GitHub (Oct 12, 2019). - Gitea version (or commit ref): 1.9.3 - Git version: 2.23.0 - Operating system: Freebsd - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: https://gist.github.com/carc1n0gen/85b5b52130ea7be722eb85da202be158 ## Description I created a repo on my gitea instance, added as a remote on an existing repo, and pushed. That was fine. I then noticed the releases page was empty since I hadn't pushed the tags. So I pushed the tags. Now the releases page yields a 500 error page. The repo is public, so here it is: https://gitea.carsonevans.ca/carson/quickpaste/releases
GiteaMirror commented 2025-11-02 05:38:11 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Oct 12, 2019):

Could be that you have pushed tags for branches that are not pushed to repo?

@lafriks commented on GitHub (Oct 12, 2019): Could be that you have pushed tags for branches that are not pushed to repo?
GiteaMirror commented 2025-11-02 05:38:11 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 12, 2019):

All of the tags are version tags off of master unless I made a mistake along the way. Is there a way to find out? But I am very confident I've only ever tagged off master

EDIT: I've only ever had maybe 4 temp branches besides master on this repo.

@carc1n0gen commented on GitHub (Oct 12, 2019): All of the tags are version tags off of master unless I made a mistake along the way. Is there a way to find out? But I am very confident I've only ever tagged off master EDIT: I've only ever had maybe 4 temp branches besides master on this repo.
GiteaMirror commented 2025-11-02 05:38:12 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 12, 2019):

I think if that were the case, I would have been able to reproduce on the try.gitea.io instance

@carc1n0gen commented on GitHub (Oct 12, 2019): I think if that were the case, I would have been able to reproduce on the try.gitea.io instance
GiteaMirror commented 2025-11-02 05:38:13 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 12, 2019):

If someone wants to take a look at my database I can send it. There's no secret repos in it. I'll scrub the password hashes first (its just me)

@carc1n0gen commented on GitHub (Oct 12, 2019): If someone wants to take a look at my database I can send it. There's no secret repos in it. I'll scrub the password hashes first (its just me)
GiteaMirror commented 2025-11-02 05:38:13 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 12, 2019):

Hmm, those logs are xorm logs. Is there any console output? For a 500 you should have something logged.

Another option is to switch the RUN_MODE from prod to dev in app.ini

In fact that would probably be quite helpful as we should see the trace of the error.

@zeripath commented on GitHub (Oct 12, 2019): Hmm, those logs are xorm logs. Is there any console output? For a 500 you should have something logged. Another option is to switch the `RUN_MODE` from prod to `dev` in app.ini In fact that would probably be quite helpful as we should see the trace of the error.
GiteaMirror commented 2025-11-02 05:38:14 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 12, 2019):

2019/10/12 16:59:43 ...ters/repo/release.go:115:Releases() [E] calReleaseNumCommitsBehind: GetBranchCommit: object not found

Sounds like I am indeed missing a referenced branch from that error? The problem is this project began on GitHub, and I'm migrating it to gitea. I've pushed the only branch I still have lying around to gitea with no luck. Not sure where to go from here.

@carc1n0gen commented on GitHub (Oct 12, 2019): ``` 2019/10/12 16:59:43 ...ters/repo/release.go:115:Releases() [E] calReleaseNumCommitsBehind: GetBranchCommit: object not found ``` Sounds like I am indeed missing a referenced branch from that error? The problem is this project began on GitHub, and I'm migrating it to gitea. I've pushed the only branch I still have lying around to gitea with no luck. Not sure where to go from here.
GiteaMirror commented 2025-11-02 05:38:14 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 12, 2019):

So that's coming from:

3249c0ccba/routers/repo/release.go (L36-L40)

@zeripath commented on GitHub (Oct 12, 2019): So that's coming from: https://github.com/go-gitea/gitea/blob/3249c0ccba5b3082fe60f4b571159016db6d57d7/routers/repo/release.go#L36-L40
GiteaMirror commented 2025-11-02 05:38:15 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 12, 2019):

And from your logs it looks like it's release id 10

@zeripath commented on GitHub (Oct 12, 2019): And from your logs it looks like it's release id 10
GiteaMirror commented 2025-11-02 05:38:15 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 12, 2019):

Now this is odd, because we first of all test is the BranchExists and then when we try to get the commit it fails.

So it's a bit weird. Either one of these is lying to us or the git object db and it's references are broken.

Hmm what to do... I guess it would be nice to find out what the target is - that can be done by interrogating the database.

Then it would be helpful to check the git repository on the server to see if that target is there.

It could be that the tags haven't been pushed completely or some other weirdness.

Another thing is to check those functions above to see if they really are looking at the same thing

@zeripath commented on GitHub (Oct 12, 2019): Now this is odd, because we first of all test is the BranchExists and then when we try to get the commit it fails. So it's a bit weird. Either one of these is lying to us or the git object db and it's references are broken. Hmm what to do... I guess it would be nice to find out what the target is - that can be done by interrogating the database. Then it would be helpful to check the git repository on the server to see if that target is there. It could be that the tags haven't been pushed completely or some other weirdness. Another thing is to check those functions above to see if they really are looking at the same thing
GiteaMirror commented 2025-11-02 05:38:16 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 12, 2019):

Very early in the project I did rebase master one time. I know thats a no-no, but the project wasn't public yet, and I already had some tagged releases. Would that have this effect? I'll try to take a look at the db and see what release id 10 points at

@carc1n0gen commented on GitHub (Oct 12, 2019): Very early in the project I did rebase master one time. I know thats a no-no, but the project wasn't public yet, and I already had some tagged releases. Would that have this effect? I'll try to take a look at the db and see what release id 10 points at
GiteaMirror commented 2025-11-02 05:38:16 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 12, 2019):

This is the release record:

10|10|1|v2.0.4|v2.0.4|||e7e16cf155afc2c77733dd8081cef28612021eca|11||0|0|1548175363|1

I'll take a look at that tag

@carc1n0gen commented on GitHub (Oct 12, 2019): This is the release record: ``` 10|10|1|v2.0.4|v2.0.4|||e7e16cf155afc2c77733dd8081cef28612021eca|11||0|0|1548175363|1 ``` I'll take a look at that tag
GiteaMirror commented 2025-11-02 05:38:16 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 13, 2019):

It's the target you should be looking at. In your record it appears to be empty.

Not sure why it would be that way though.

@zeripath commented on GitHub (Oct 13, 2019): It's the target you should be looking at. In your record it appears to be empty. Not sure why it would be that way though.
GiteaMirror commented 2025-11-02 05:38:17 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 13, 2019):

Okay. What data from the tag should be there? Even if we can't figure out why it's missing, I'd like fix it so I can use the releases page. Or maybe I should just remove the record/tag and move on?

@carc1n0gen commented on GitHub (Oct 13, 2019): Okay. What data from the tag should be there? Even if we can't figure out why it's missing, I'd like fix it so I can use the releases page. Or maybe I should just remove the record/tag and move on?
GiteaMirror commented 2025-11-02 05:38:17 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 13, 2019):

I guess you could just add the tag name as the target? Assuming it's present in the git references. Just double check it's actually empty because if it's not we're going down the wrong route.

I don't know this bit of code at all - I've never actually looked at it. So I literally have no idea how it have gone wrong. Target clearly needs to be a commit reference that git can find.

TBF It's a bit crap that one error in one release causes a 500 - I think this needs a review.

IsBranchExist is probably to blame though here - it shouldn't be returning true if the target is empty or can't be got. So I think I'm gonna look at that first.

@zeripath commented on GitHub (Oct 13, 2019): I guess you could just add the tag name as the target? Assuming it's present in the git references. Just double check it's actually empty because if it's not we're going down the wrong route. I don't know this bit of code at all - I've never actually looked at it. So I literally have no idea how it have gone wrong. Target clearly needs to be a commit reference that git can find. TBF It's a bit crap that one error in one release causes a 500 - I think this needs a review. IsBranchExist is probably to blame though here - it shouldn't be returning true if the target is empty or can't be got. So I think I'm gonna look at that first.
GiteaMirror commented 2025-11-02 05:38:18 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 13, 2019):

IsBranchExist is:

5e759b60cc/modules/git/repo_branch.go (L29-L33)

I suspect this might return true I think if name was empty.

So that's probably a problem.

@zeripath commented on GitHub (Oct 13, 2019): IsBranchExist is: https://github.com/go-gitea/gitea/blob/5e759b60cca3cd8484a6235fcc9120d18e8cd455/modules/git/repo_branch.go#L29-L33 I suspect this might return true I think if name was empty. So that's probably a problem.
GiteaMirror commented 2025-11-02 05:38:18 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 13, 2019):

ee11974719/modules/git/repo_commit.go (L147-L154)

ee11974719/modules/git/repo_commit.go (L37-L40)

So if name is empty this would cause your error.

@zeripath commented on GitHub (Oct 13, 2019): https://github.com/go-gitea/gitea/blob/ee11974719528197241840dc245f7daf08ec5c0a/modules/git/repo_commit.go#L147-L154 https://github.com/go-gitea/gitea/blob/ee11974719528197241840dc245f7daf08ec5c0a/modules/git/repo_commit.go#L37-L40 So if name is empty this would cause your error.
GiteaMirror commented 2025-11-02 05:38:19 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 13, 2019):

The target is for sure empty

@carc1n0gen commented on GitHub (Oct 13, 2019): The target is for sure empty
GiteaMirror commented 2025-11-02 05:38:20 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 13, 2019):

If you're able to rebuild Gitea you could try adjusting IsBranchExist to check if name is empty before it does the reference check by adding:

if name == "" {
  return false
}

Appropriately fmt'd of course.

@zeripath commented on GitHub (Oct 13, 2019): If you're able to rebuild Gitea you could try adjusting `IsBranchExist` to check if name is empty before it does the reference check by adding: ```go if name == "" { return false } ``` Appropriately fmt'd of course.
GiteaMirror commented 2025-11-02 05:38:20 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 13, 2019):

I'm using the binary package provided from freebsd so I cannot do that.

@carc1n0gen commented on GitHub (Oct 13, 2019): I'm using the binary package provided from freebsd so I cannot do that.
GiteaMirror commented 2025-11-02 05:38:20 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 13, 2019):

So it actually turns out that every release record from that release and onward have an empty target. No idea why that is, and not sure what to do at this point.

Not a single release record has a target and there are 51 of them

@carc1n0gen commented on GitHub (Oct 13, 2019): ~So it actually turns out that *every* release record from that release and onward have an empty target. No idea why that is, and not sure what to do at this point.~ Not a single release record has a target and there are 51 of them
GiteaMirror commented 2025-11-02 05:38:21 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 13, 2019):

Oks I should just check that this function hasn't changed between 1.10 and 1.9.3

They haven't.

@zeripath commented on GitHub (Oct 13, 2019): Oks I should just check that this function hasn't changed between 1.10 and 1.9.3 They haven't.
GiteaMirror commented 2025-11-02 05:38:21 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 13, 2019):

Where have you got this FreeBSD release? Is it the Darwin release?

@zeripath commented on GitHub (Oct 13, 2019): Where have you got this FreeBSD release? Is it the Darwin release?
GiteaMirror commented 2025-11-02 05:38:22 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 13, 2019):

No Darwin is macOS. FreeBSD has it in their package manager, so they're building it themselves. I get updates when installing updates to installed packages and it prints out additional instructions in the case there were changes that require manual intervention, which has happened in the past.

@carc1n0gen commented on GitHub (Oct 13, 2019): No Darwin is macOS. FreeBSD has it in their package manager, so they're building it themselves. I get updates when installing updates to installed packages and it prints out additional instructions in the case there were changes that require manual intervention, which has happened in the past.
GiteaMirror commented 2025-11-02 05:38:22 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 13, 2019):

OK, well that means that I cannot test if my fix works because I can't build it for you.

There's also the potential issue that you're looking at a bug introduced by the FreeBSD port - or some weirdness to do with it.

Looking again at #8485 I can't see why it shouldn't work originally unless that go-git does something on freebsd...

Is there any chance you could check whether the problem exists using the same DB and repos on linux, or can reproduce it on try.gitea.io?

@zeripath commented on GitHub (Oct 13, 2019): OK, well that means that I cannot test if my fix works because I can't build it for you. There's also the potential issue that you're looking at a bug introduced by the FreeBSD port - or some weirdness to do with it. Looking again at #8485 I can't see why it shouldn't work originally unless that go-git does something on freebsd... Is there any chance you could check whether the problem exists using the same DB and repos on linux, or can reproduce it on try.gitea.io?
GiteaMirror commented 2025-11-02 05:38:23 -06:00
Author
Owner
Copy Link

@carc1n0gen commented on GitHub (Oct 13, 2019):

My original post indicates I was not able to reproduce on try.gitea.io. I'll try to find the proper channels to investigate the freebsd port

@carc1n0gen commented on GitHub (Oct 13, 2019): My original post indicates I was not able to reproduce on try.gitea.io. I'll try to find the proper channels to investigate the freebsd port
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#4106
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?