Gitea: Tons of panic errors with GZIP enabled

[HorlogeSkynet]

• Gitea version (or commit ref): v1.10.0
• Git version: v2.20.1
• Operating system: Debian Buster
• Database (use [x]):
  
  
  
  • [X] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [X] Not relevant
  
  
• Log gist: https://pastebin.com/48z5b0FL

Description

Hey everyone !
It seems like there has been some issues with GZIP for some minor versions from now.
I can't really figure out since _when_, as logs have been polluted and rotated for weeks.
The error attached above is thrown every ~20 seconds when GZIP is enabled on my setup.
Still happening against v1.9.6 and v1.10.0 .

I can provide further details if you guys got some ideas to narrow down the diagnostic.

Bye, thanks 👋

[zeripath]

Ok. We need the precise version of Gitea. routers/repo/repo.go appears to be one of the more active parts of our code so line 342 isn't too helpful.

Do you have a SHA hash for the commit that made those logs?

[zeripath]

It would also be helpful to see the router logs and surrounding logging

[zeripath]

Assuming that 1.10 produced that log the implication is that this caused the panic:

https://github.com/go-gitea/gitea/blob/9619ccf0e54c0f8502b5e1bc7dad4d3471330f9c/routers/repo/repo.go#L342

Which doesn't exactly make a lot of sense

[zeripath]

Basically either ctx.User is nil or ctx.Repo.Repository / ctx.Repo is nil.

[zeripath]

Assuming that is the causative line, repo.Action matches the following endpoint:

https://github.com/go-gitea/gitea/blob/9619ccf0e54c0f8502b5e1bc7dad4d3471330f9c/routers/routes/routes.go#L684

[zeripath]

Which sort of implies that you're try to star a repository but why would you be doing that so often... It's weird.

[HorlogeSkynet]

It's definitely v1.10.0 .
It looks like my instance is being hard-crawled (so huge amount of unauthenticated requests) for some days now (🤷‍♂).

By increasing the log level, I've managed to reproduce the error on my own.
It appears when requesting something like : https://$HOSTNAME/$OWNER/$REPOSITORY/action/watch?redirect_to=$URL_ENCODED_FILE_LOCATION.
Symmetrically, as you pointed out, trying to star is equivalent.
Errors come up, but the back-end correctly redirects to the authentication page.

So, is it _just_ about a null-able variable being used somewhere ?

Thanks for the quick feedback @zeripath 🙇

EDIT (important) : With GZIP disabled, I still cannot reproduce the behavior.

[zeripath]

It's weird it's like things are not being cancelled when the user is denied - I'll have to take a look.

[zeripath]

Ah damn... When I reimplemented this I just copied the behaviour that was there before...

it was wrong then and it is wrong now.

We need to actually properly implement all the context response writer methods - or - change the internal writer of the context response writer.

[HorlogeSkynet]

Thanks again @zeripath, that was awesome and quick 👌
Can't wait to see the next release being drafted !
@++ 👋