As seen in https://pagure.io/fedora-infrastructure/issue/10865
When a build is submitted with numerous dependencies to resolve, the frontend stalls and causes builds to fail. This also causes the frontend as a whole to become unresponsive, even though there are multiple httpd threads available.
From the original ticket:
I don't believe the frontend was ever intended to handle overly long requests. The real work of building modules is supposed to happen in the backend. I believe the frontend was intended to accept the build parameters, perform basic validation, and pass the rest off to the backend. Unfortunately, dependency resolution happens at submission time and it appears we've found some cases where that resolution takes entirely too long, causing timeouts and jamming up the frontend. So, I think that gives us two ways to attack this. FIrst, make the resolution faster if we can (there could be a bug or infra situation here slowing things down). Second, shift this now-more-expensive calculation to the backend, where it can be handled asynchronously. The catch is the latter is likely a significant api change. The first option is likely safest, if it works. We should probably start by replicating the problematic submission in a way that we can trace it and see where the slowdowns are happening.
I don't believe the frontend was ever intended to handle overly long requests. The real work of building modules is supposed to happen in the backend. I believe the frontend was intended to accept the build parameters, perform basic validation, and pass the rest off to the backend. Unfortunately, dependency resolution happens at submission time and it appears we've found some cases where that resolution takes entirely too long, causing timeouts and jamming up the frontend.
So, I think that gives us two ways to attack this. FIrst, make the resolution faster if we can (there could be a bug or infra situation here slowing things down). Second, shift this now-more-expensive calculation to the backend, where it can be handled asynchronously. The catch is the latter is likely a significant api change.
The first option is likely safest, if it works. We should probably start by replicating the problematic submission in a way that we can trace it and see where the slowdowns are happening.
Any progress? I rebuild modules for Fedora 39 and run into this issue again.
I'm unable to submit perl-CGI:4.54 from into Fedora MBS at all. It always times out. Even if I removed 120s timeout from fedpkg. I was removing contexts until keeping only one:
- context: '1f39p536' platform: f39 buildrequires: perl: ['5.36'] perl-libwww-perl: ['6.67'] requires: perl: ['5.36'] perl-libwww-perl: ['6.67'] buildopts: rpms: macros: | %_without_perl_CGI_enables_optional_test 1
at it still times out. We are unable to build modules because of it. Interesting fact is that last year Fedora MBS accepted this 8-contexts module build.
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/koji/mbs/issues/1759
Please continue any further discussion there.