404 when reviewing/creating PRs

[rossigee]

• Gogs version (or commit ref): 0.10.34.0401 / 0.11 RC
• Git version: as per latest Docker image
• Operating system: Linux
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gogs.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist (usually found in log/gogs.log):

2017/04/03 08:11:44 [TRACE] Session ID: 849f6bee671377d2
2017/04/03 08:11:44 [TRACE] CSRF Token: zFr1fBNdQSz6QKK3vv3yovCnihA6MTQ5MTE5OTQ4ODI5MzM4NzI4OQ==
2017/04/03 08:11:46 [TRACE] Template: status/404

Description

Unable to create or review PRs. It just comes back with 404 page. Example URI...

https://gogs.mydomain.com/myproject/myrepo/compare/master...feature-3963-events-model

[unknwon]

Can you reproduce the bug at https://try.gogs.io:
No

Why?

[rossigee]

Because it works at that URL, just not on my instance :)

Thinking back, I upgraded the Docker container (gogs/gogs official container) twice in the last month or so to fix other bugs, and it's started being a problem since then. I suspect it could be a database migration failure. However, I see nothing in the log files that would confirm/deny that as the cause (just the three TRACE lines, quoted above), otherwise I could attempt to identify and apply the missing

If there were SQL errors, where would I find them?

If I can identify it as a missing field/table/schema update, where can I find the migration queries run between versions so I can attempt to manually apply them to fix our instance?

Cheers for all your work on GOGS, btw.

[unknwon]

Please provide reproduce steps.

[rossigee]

At this point, I don't think it's a bug in GOGS, so it probably can't be reproduced elsewhere.

This is more of a request for support now, to help me (and maybe others) to identify and resolve 404 errors that might be caused by broken database migrations.

I do have an older backup I can use as a last resort, but if this can be fixed manually with a little investigation/debugging and some SQL updates, without losing any data, that would be the best option.

[unknwon]

1. This is not a place for user support
2. I have absolutely no context about why should https://gogs.mydomain.com/myproject/myrepo/compare/master...feature-3963-events-model not be 404.
3. It is Gogs

[rossigee]

I would be interested to know why GOGS shows an ambiguous 404 error rather than a more explanatory error message. Also, why nothing in the log files to explain - what can't it find?

I'm not a go developer, but am curious enough that if you can tell me where I can add debug lines to narrow it down, I'd be happy to try.

[rossigee]

Where's a better place for support questions?

[unknwon]

If you have read issue post template, it is https://discuss.gogs.io/

[rossigee]

Apologies. To begin with, I was thinking it was a bug. I'll raise the issue there instead.

[unknwon]

As a user, you should explain why something should happen the way you expect. Otherwise I can't help you solve the problem because I have no idea what is going on.

[rossigee]

You mean like...?

Click on 'pull request' from branches view.

Expected behaviour: Display PR form to provide more details.
Actual behaviour: Ambiguous 404 error with no error message or log entries.

You're right, that would have been more helpful, but your bug report form doesn't ask for that specifically. I just answered the questions it asked and tried to provide as much information as I could (which wasn't much!).

[unknwon]

OK, I might know the problem. Has your repository disabled pull request?

[unknwon]

I reproduced the problem if I disable pull request for my repository, the button on branches page shouldn't be showed at all.

Patch has pushed to fix this issue, please test on develop branch or https://try.gogs.io.

[rossigee]

Yes, the 'enable pull requests' tickbox was unticked. I've ticked it and I can now create new pull requests and review ones that were created before the upgrade. Thank you!

So, PRs were working fine in previous versions, then one recent upgrade introduced this new tickbox, which defaults to false, which broke our ability to access PRs that were already open.

I have a couple of suggestions :

1. Instead of presenting 404 if PRs are disabled for a repo:
   a) present an error message saying 'PRs are not enabled on this repository', and perhaps allow for any existing PRs to still be processed or otherwise cleared down.
   b) If PRs are not enabled, remove the 'pull request' button from the branches view :)

2. Change the wording in the settings to just 'Enable pull requests', as 'Enable pull requests to accept public contributions' sounds wrong if it is a private repository, not a public one.

[rossigee]

Wow! You work fast. You fixed it in the code before I'd finished typing it up on this ticket :)

[unknwon]

This button has been there for quite ... a few months. And the default is ... true.

[rossigee]

Odd. I can only presume someone unticked it by mistake, perhaps confused because they thought it would allow to 'accept public contributions'.

Anyway, thanks again. Problem now solved at our end.