Upgrader no-JS fallback is really annoying

[Colonel_mortis]

If one request times out in the JS upgrader, it falls back to the considerably slower HTML-based upgrader. Could there not be some logic to retry the request a couple of times, ideally with a bit of backoff (if it's an nginx or transport layer error it's probably a timeout, and retrying will then hit the case where the task is already done), rather than making the upgrade experience suck? At worst, the HTML upgrader shouldn't have delays between redirects - as soon as the response comes back it is ready to receive another request.

It's reasonably easy to work around by just deleting the mr parameter from the URL, but that relies on me paying attention to the upgrader.

Edited October 25, 2020 by Colonel_mortis

[CoffeeCake]

YES.

[Charles]

This only happens if your server is having problems processing an upgrade action in a reasonable amount of time. If it happens, you can always exit your browser and restart the upgrader. It will remember where it left off and try the proper way again.

[TSP]

On 10/27/2020 at 1:58 PM, Charles said:

This only happens if your server is having problems processing an upgrade action in a reasonable amount of time. If it happens, you can always exit your browser and restart the upgrader. It will remember where it left off and try the proper way again.

I also find the current behaviour here frustrating, as it's so much slower, and it happens quite often for the big boards I work on. I've often found ongoing COUNT(*)-queries to be the culprit, which is kind of ironic since the purpose of them is to figure out whether the table is so big that queries against them will take a long time or not.

Could you at least lower the refresh time? It's currently 2 seconds and should ideally be instant. If instant isn't feasible, then at least let it be 1 second.  

Edited October 30, 2020 by TSP

[Charles]

8 hours ago, TSP said:

I also find the current behaviour here frustrating, as it's so much slower, and it happens quite often for the big boards I work on. I've often found ongoing COUNT(*)-queries to be the culprit, which is kind of ironic since the purpose of them is to figure out whether the table is so big that queries against them will take a long time or not.

Could you at least lower the refresh time? It's currently 2 seconds and should ideally be instant. If instant isn't feasible, then at least let it be 1 second.  

A basic query like COUNT(*) should be almost instant. If it's not then you should probably look at your server to see what is wrong. We host sites with tens of millions of posts without issue.

[Colonel_mortis]

On 10/27/2020 at 12:58 PM, Charles said:

This only happens if your server is having problems processing an upgrade action in a reasonable amount of time. If it happens, you can always exit your browser and restart the upgrader. It will remember where it left off and try the proper way again.

I have turned up the threshold for falling back to manual queries, because the vast majority of the time the queries that require manual action only take a couple of seconds to run (even with the threshold turned up). Maybe if I turn it down that will solve the issue, but instead it will mean I spend time copying queries into mysql-client instead. That raises another question though - can you fix the query runtime heuristic to be more accurate? UPDATE queries are pretty fast, as are DROP INDEX and I think DROP COLUMN, whereas CREATE INDEX queries are very slow, but they're all judged by the same threshold.

Given the replies above though, as well as my memory of prior upgrades where I hadn't updated the threshold, resetting the threshold back to default is not the magic bullet here.

[bfarber]

We may be able to look at making the suggestions of when to run queries "smarter", of course.