mirror of
https://github.com/go-gitea/gitea.git
synced 2026-03-09 04:25:18 -05:00
Error 500 on comment creation via API, with sudo #2828
Closed
opened 2025-11-02 04:49:56 -06:00 by GiteaMirror
·
36 comments
No Branch/Tag Specified
main
release/v1.25
release/v1.24
release/v1.23
release/v1.22
release/v1.21
release/v1.20
release/v1.19
release/v1.18
release/v1.17
release/v1.16
release/v1.15
release/v1.14
release/v1.13
release/v1.12
release/v1.11
release/v1.10
release/v1.9
release/v1.8
v1.25.3
v1.25.2
v1.25.1
v1.25.0
v1.24.7
v1.25.0-rc0
v1.26.0-dev
v1.24.6
v1.24.5
v1.24.4
v1.24.3
v1.24.2
v1.24.1
v1.24.0
v1.23.8
v1.24.0-rc0
v1.25.0-dev
v1.23.7
v1.23.6
v1.23.5
v1.23.4
v1.23.3
v1.23.2
v1.23.1
v1.23.0
v1.23.0-rc0
v1.24.0-dev
v1.22.6
v1.22.5
v1.22.4
v1.22.3
v1.22.2
v1.22.1
v1.22.0
v1.23.0-dev
v1.22.0-rc1
v1.21.11
v1.22.0-rc0
v1.21.10
v1.21.9
v1.21.8
v1.21.7
v1.21.6
v1.21.5
v1.21.4
v1.21.3
v1.21.2
v1.20.6
v1.21.1
v1.21.0
v1.21.0-rc2
v1.21.0-rc1
v1.20.5
v1.22.0-dev
v1.21.0-rc0
v1.20.4
v1.20.3
v1.20.2
v1.20.1
v1.20.0
v1.19.4
v1.21.0-dev
v1.20.0-rc2
v1.20.0-rc1
v1.20.0-rc0
v1.19.3
v1.19.2
v1.19.1
v1.19.0
v1.19.0-rc1
v1.20.0-dev
v1.19.0-rc0
v1.18.5
v1.18.4
v1.18.3
v1.18.2
v1.18.1
v1.18.0
v1.17.4
v1.18.0-rc1
v1.19.0-dev
v1.18.0-rc0
v1.17.3
v1.17.2
v1.17.1
v1.17.0
v1.17.0-rc2
v1.16.9
v1.17.0-rc1
v1.18.0-dev
v1.16.8
v1.16.7
v1.16.6
v1.16.5
v1.16.4
v1.16.3
v1.16.2
v1.16.1
v1.16.0
v1.15.11
v1.17.0-dev
v1.16.0-rc1
v1.15.10
v1.15.9
v1.15.8
v1.15.7
v1.15.6
v1.15.5
v1.15.4
v1.15.3
v1.15.2
v1.15.1
v1.14.7
v1.15.0
v1.15.0-rc3
v1.14.6
v1.15.0-rc2
v1.14.5
v1.16.0-dev
v1.15.0-rc1
v1.14.4
v1.14.3
v1.14.2
v1.14.1
v1.14.0
v1.13.7
v1.14.0-rc2
v1.13.6
v1.13.5
v1.14.0-rc1
v1.15.0-dev
v1.13.4
v1.13.3
v1.13.2
v1.13.1
v1.13.0
v1.12.6
v1.13.0-rc2
v1.14.0-dev
v1.13.0-rc1
v1.12.5
v1.12.4
v1.12.3
v1.12.2
v1.12.1
v1.11.8
v1.12.0
v1.11.7
v1.12.0-rc2
v1.11.6
v1.12.0-rc1
v1.13.0-dev
v1.11.5
v1.11.4
v1.11.3
v1.10.6
v1.12.0-dev
v1.11.2
v1.10.5
v1.11.1
v1.10.4
v1.11.0
v1.11.0-rc2
v1.10.3
v1.11.0-rc1
v1.10.2
v1.10.1
v1.10.0
v1.9.6
v1.9.5
v1.10.0-rc2
v1.11.0-dev
v1.10.0-rc1
v1.9.4
v1.9.3
v1.9.2
v1.9.1
v1.9.0
v1.9.0-rc2
v1.10.0-dev
v1.9.0-rc1
v1.8.3
v1.8.2
v1.8.1
v1.8.0
v1.8.0-rc3
v1.7.6
v1.8.0-rc2
v1.7.5
v1.8.0-rc1
v1.9.0-dev
v1.7.4
v1.7.3
v1.7.2
v1.7.1
v1.7.0
v1.7.0-rc3
v1.6.4
v1.7.0-rc2
v1.6.3
v1.7.0-rc1
v1.7.0-dev
v1.6.2
v1.6.1
v1.6.0
v1.6.0-rc2
v1.5.3
v1.6.0-rc1
v1.6.0-dev
v1.5.2
v1.5.1
v1.5.0
v1.5.0-rc2
v1.5.0-rc1
v1.5.0-dev
v1.4.3
v1.4.2
v1.4.1
v1.4.0
v1.4.0-rc3
v1.4.0-rc2
v1.3.3
v1.4.0-rc1
v1.3.2
v1.3.1
v1.3.0
v1.3.0-rc2
v1.3.0-rc1
v1.2.3
v1.2.2
v1.2.1
v1.2.0
v1.2.0-rc3
v1.2.0-rc2
v1.1.4
v1.2.0-rc1
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.2
v1.0.1
v1.0.0
v0.9.99
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
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
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/gitea#2828
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking 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 @jlecour on GitHub (Jan 27, 2019).
[x]):Description
I've been using the API to import projects and issues from Redmine/Gitolite to Gitea (it will be open sourced soon).
For a few days I've been using a Gitea instance with a version < 1.7 and it seemed to work really well. I could create issues and comments on repositories, with or without the
Sudoheader.It seems that after the 1.7 upgrade I can't use
Sudoanymore.My request fail if I add the HTTP header. I get the same error with the query string parameter.
Examples :
Obviously
other_userexists and is a collaborator on the repository withWritepermission.In the logs, I only get SQL logs with a failed transaction (ROLLBACK). I've executed each request manually against my database and I get no error, so I guess the faulty request is not logged.
I'm not sure if it's a bug or if I did something wrong.
Is there a way to have more information about the error ?
@jlecour commented on GitHub (Jan 27, 2019):
I've tried this on try.gitea.org but I can't get to use
sudosince I'm not an administrator.@jlecour commented on GitHub (Jan 27, 2019):
Another strange fact : I can create issues with
Sudo(and the same user, on the same repository), but it fails for comments@zeripath commented on GitHub (Jan 27, 2019):
Oo that's interesting... Just tried this on master on my local machine.I can get a 500 if I fail to log in correctly:
It's de-referencing null because ctx.User isn't actually set
anymore.Nasty.
I don't understand how the tests didn't pick this up.I've put in a PR to fix this.
@zeripath commented on GitHub (Jan 27, 2019):
OK, I think I've spotted a different bug, because I wasn't actually properly logging in... So I was getting a null pointer - which is bad enough to require a patch in itself...
@zeripath commented on GitHub (Jan 27, 2019):
I'm not able to completely replicate your issue on master. Let me check on 1.7.0
@jlecour commented on GitHub (Jan 27, 2019):
Is there a special mode I can run my instance with to help you debug this ?
@zeripath commented on GitHub (Jan 27, 2019):
Hmm... I can't replicate with a valid token. I can get a 500 if the token is invalid though and I've just put a PR in for that. Are you sure that your token is correct?
@zeripath commented on GitHub (Jan 27, 2019):
Is there something special about that issue?
@zeripath commented on GitHub (Jan 27, 2019):
I guess you aren't getting the above nil dereference error?
@jlecour commented on GitHub (Jan 27, 2019):
As far as I can tell, my token is working.
I've been using it to create/delete repositories and issues (with Sudo), add collaborators to a repository…
I just can't post a comment with Sudo :/
@zeripath commented on GitHub (Jan 27, 2019):
If you're getting a ROLLBACK then something is causing a conflict in the database - which is very odd.
@jlecour commented on GitHub (Jan 27, 2019):
It's working perfectly with
1.6.3but not with1.7.0.@zeripath commented on GitHub (Jan 27, 2019):
I suspect its something to do with my fixing of deadlocks patches. There's a cascade of actions that come after the creation of an issue comment. I wonder if one of them isn't working within the session...
@jlecour commented on GitHub (Jan 27, 2019):
It's also OK with
1.6.4.@zeripath commented on GitHub (Jan 27, 2019):
OK presumably the conflict is occurring in here: https://github.com/go-gitea/gitea/blob/master/models/issue_comment.go#L544
@zeripath commented on GitHub (Jan 27, 2019):
Do you have watchers on your issue or have webhooks?
@jlecour commented on GitHub (Jan 27, 2019):
No watchers on the comment.
Since it's an import job from another code hosting system, the issue is created and the comments are added right after that.
There is also no webhooks nor Git hooks.
@zeripath commented on GitHub (Jan 27, 2019):
There's nothing trying to post at the same time is there? Maybe you're both trying to post at the same time although there really should be an error thrown back to you.
@zeripath commented on GitHub (Jan 27, 2019):
Could you post your db log with the rollback in it? And what dB are you using?
@jlecour commented on GitHub (Jan 27, 2019):
I don't think anything tries to post at the same time. It's a procedural script.
Here is the DB log :
@zeripath commented on GitHub (Jan 27, 2019):
Hmm I wonder I don't think this is necessary: https://github.com/go-gitea/gitea/blob/master/models/issue_comment.go#L533Does commenting it out make your problem go away?That's necessary
@zeripath commented on GitHub (Jan 27, 2019):
No. It shouldn't be that.
It could be this
6311e4ce6a/models/repo_watch.go (L90)That loads the repository outside of the transaction.
@jlecour commented on GitHub (Jan 27, 2019):
Are you asking me to download the source code, comment the
Ifblock, recompile and try again?If so, I need instructions because I’ve never compiled a Go project yet.
@zeripath commented on GitHub (Jan 27, 2019):
You probably have only just started noticing it because I might have missed it in my deadlock fixing set which probably moved the notifyWatchers bit into the transaction.
@zeripath commented on GitHub (Jan 27, 2019):
If you want it fixed today, yes. I'm afraid it's almost midnight here and I'm going to bed. My day job is very different from coding so I won't be able to hack until the evening.
The
act.loadRepo()function is defined here:7d65ddf5e1/models/action.go (L117)Go isn't that hard - it's yet another imperative language with a garbage collector. If it helps, up until my first patch in August I had never written a line of it. There's some instructions on Gitea.io. See if you can recruit some help on discord too.
Otherwise I can fix it tomorrow. Hopefully I've identified the right bug so it should be quick to sort.
PS it's no longer a comment out the block btw, the act.loadrepo code needs to be pulled within the transaction by passing the session e in and using that. If no session is available then you can pass in x and it will work.
@zeripath commented on GitHub (Jan 27, 2019):
https://docs.gitea.io/en-us/install-from-source/ is the basic build instructions.
@jlecour commented on GitHub (Jan 28, 2019):
@zeripath Hey, I'm sorry if I was a bit blunt.
I did not expect anything, and certainly not to have it fixed and delivered for free the same day.
I'm very thankful for your quick response to my issue. You took from your limited personal time to help me and that's very appreciated.
I'm not sure that I'll be able to setup a test instance of gitea to try the proposed fix without impacting my production instance. I can stay on 1.6.4 until this is properly investigated and fixed. I will report if I can do more on my side.
Thanks again.
@zeripath commented on GitHub (Jan 28, 2019):
OK, so looking at this again. The
act.loadRepo()should be fine - we create it with that set.What is interesting though is that your xorm.log appears to effectively call notifyWatchers twice.
@zeripath commented on GitHub (Jan 28, 2019):
AHA! It's this https://github.com/go-gitea/gitea/blob/release/v1.7/models/issue_comment.go#L635 - which is not in master.
@zeripath commented on GitHub (Jan 28, 2019):
So #5110 probably silently fixed this issue.
@lunny, do you think it would be reasonable to backport #5110 to v1.7.0 to fix this issue.
@jlecour could you try on latest to see if you can replicate your issue?
@jlecour commented on GitHub (Jan 28, 2019):
@zeripath Good news !
Which commit/tag/branch should I try to compile and run ?
@adelowo commented on GitHub (Jan 28, 2019):
@jlecour Master branch
@jlecour commented on GitHub (Jan 28, 2019):
OK, compiling Gitea was really easy !
I've verified that master doesn't have the bug I've found anymore.
Thanks you @zeripath you've been amazing !
If by any chance you are at FOSDEM in Brussels next weekend, I'd be happy to thank your personally.
@zeripath commented on GitHub (Jan 28, 2019):
No worries. Afraid I won't be at fosdem unfortunately, never been.
I'll have another think about this bug - I suspect that others were likely to be hit by it - it's likely to be in the mail creation scripts but I can't seem to replicate it. Tell me what dB are you using? I guess you've got email switched on too?
@jlecour commented on GitHub (Jan 28, 2019):
I've been using MySQL and yes I have mail notifications enabled.
@zeripath commented on GitHub (Jan 29, 2019):
This is probably actually the bug in #5891 - well when it's backported.