#9165 src.fedoraproject.org/user/churchyard/requests always timeouts
Closed: Fixed by pingou. Opened by churchyard.

Describe what you would like us to do:

I've been trying to access https://src.fedoraproject.org/user/churchyard/requests for many days now, but it always gives 504 Gateway Timeout. Could you please increase the timeout to allow me to see that page?

When do you need this to be done by? no particular time


Thanks


Metadata Update from @smooge:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: groomed, high-trouble, medium-gain, src.fp.o

After how long does it timeout?

I just loaded it here and it loaded ok in about 45 seconds...

Metadata Update from @kevin:
- Issue untagged with: groomed, high-trouble, medium-gain, src.fp.o
- Issue priority set to: Needs Review (was: Waiting on Assignee)

Sigh, thanks pagure.

Metadata Update from @kevin:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: groomed, medium-gain, medium-trouble

Apparently, it is a haisenbug, because now it loads for me as well in about 45 seconds. Sorry for the noise.

Metadata Update from @churchyard:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

This happens again.

Either I get a 504 Gateway Timeout or 500 Internal Server Error.

$ time http --timeout 99999 --headers https://src.fedoraproject.org/user/churchyard/requests
HTTP/1.1 504 Gateway Timeout
AppTime: D=60023516
Connection: Keep-Alive
Date: Sat, 19 Sep 2020 10:52:54 GMT
Keep-Alive: timeout=15, max=500
Referrer-Policy: same-origin
Server: Apache
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Fedora-ProxyServer: proxy01.iad2.fedoraproject.org
X-Fedora-RequestID: X2XjBnc4j9F6SgUTpbOnoAAAAFA
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
content-length: 247
content-type: text/html; charset=iso-8859-1
real    1m0,858s
user    0m0,426s
sys 0m0,062s

Metadata Update from @churchyard:
- Issue status updated to: Open (was: Closed)

Metadata Update from @pingou:
- Issue untagged with: groomed
- Issue tagged with: dev

Looks like this is an upstream issue, you simply have too many pull-requests opened and the page is failing to render before timing out.

I'll see if we can improve things upstream

We could also try and increase the timeout, but I'm not sure exactly where... since we have apache -> haproxy -> apache involved here.

I've manually added to the apache's config for / on pkgs01.iad2 a TimeOut 1200 and reloaded apache.

Running time http --timeout 99999 --headers https://src.fedoraproject.org/user/churchyard/requests still bails after 1 minute, so something else is timing out, perhaps Haproxy?

Metadata Update from @pingou:
- Issue assigned to pingou

Commit ae4b757e fixes this issue

Thanks, however this still gives 504.

Metadata Update from @churchyard:
- Issue status updated to: Open (was: Closed)

It's fixed upstream, it'll be in the next pagure release.

Metadata Update from @pingou:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Is there any ETA when I can use the fix?

Is there a workaround to get list of my open PRs?

@churchyard it has been merged upstream and will be in 5.12 which I hope to get out soonish (there are a few PRs that need review and merge and then we should start looking at 5.12)

Is there a workaround to get list of my open PRs?

I found a workaround:

https://src.fedoraproject.org/api/0/user/churchyard/requests/filed
https://src.fedoraproject.org/api/0/user/churchyard/requests/actionable

The new UI: https://src.stg.fedoraproject.org/user/churchyard/requests (in staging only for the moment -- more testing there more welcome)

The UI does what I need it to do and the page loads quickly enough. thanks.

As a side note, I appreciate the vacation badge (it tells 2017-08-04 on hover which is either wrong or the data on staging is really weird).

As a side note, I appreciate the vacation badge (it tells 2017-08-04 on hover which is either wrong or the data on staging is really weird).

Nice catch, I've also seen a few 500 errors, I'll check them tomorrow

Metadata
Related Pull Requests