QA » openQA Project

Just ran into a very fun corner case on our (Fedora's) openQA. For our update tests, one of the params we POST is a list of all the builds in the update (because the builds in updates can be edited, so we want to be sure openQA tests exactly the builds that were in the update at the time the job was created, and we know exactly what builds it tested).

So, someone created an update with a LOT of builds in it. And that meant the POST request to schedule one flavor for that update (the flavor with the longest name...) was just over 8190 characters long.

It seems like 8190 characters is a significant limit. For a start, it's Apache's default limit for request length, so initially this request just got a 414 from Apache, without reaching openQA at all. So I changed the LimitRequestLine setting in Apache to 16000. That caused the request to make it through to openQA, but openQA itself barfed on it. It gives a 200 response, but the content is not JSON like it ought to be, it's the HTML of the homepage. And it didn't schedule any jobs.

In the end, to get things working again, I had to do an awful hack to the scheduler code to drop some params we usually set in order to get the request length just under 8190 chars, and that made openQA complete it successfully.

I took a quick look through openQA and Mojolicious to see if I could find somewhere there with this same 8190 character request length limit, but didn't find it. So either it's in something lower than Mojolicious, or I didn't find it.

Still, I can think of another way to solve this: we could allow the use of form data for POSTing jobs, as well as/instead of query parameters. The size limits for form data are way bigger. I'm kinda worried that if somebody creates a Fedora update with even more packages, I could really be stuck :D

I'll see if I have the chops to send a PR for this next week if I have the time.