Page MenuHomePhabricator

Unable to load the newcomer homepage under certain circumstances
Closed, DuplicatePublic


Hey everyone,

I was reported by one of the Czech instructors interested in the Growth stuff that he can't load his homepage. I tried that under my Foundation account, and it worked as expected. To further investigate possible causes, I logged into production database, and fetched all Growth-related properties, in order to configure my test account in the same way as the reporter. Once done, I tried to open my homepage loads indefinitely.

For the properties (and username of the reported) that causes the homepage to load indefinitely, please see P13541 (WMF-NDA only).

For the record, when I configured my test acc homepage, I was able to "stay" on it after picking my topics (no suggested edits loaded through), and after I tried to visit it again, it just loaded immediately. I blame suggested edits filtering for now, but I may be wrong, of course.

Prioritizing as UBN (and putting to current sprint), since this might cause issues to our newcomers, and will likely need immediate engineering work.


Martin Urbanec

Event Timeline

Urbanecm_WMF triaged this task as Unbreak Now! priority.Dec 12 2020, 1:08 PM

AR wiki: Just tested by creating a new account, it is working as expected. The Homepage and the help panel are loaded correctly.

AR wiki: Just tested by creating a new account, it is working as expected. The Homepage and the help panel are loaded correctly.

You need to pick the right topics (for it to break at cswiki), see the restricted paste (I'll add you there in a second).

@kostajh Possibly, I saw that one a while ago, but thought it got fixed, so filled a new one w/o searching.

If this is indeed a dupe of T267216, I do think we should increase the priority of T267216 – as soon as a newcomer manages to choose the "right" values for the topics, they're basically locked out of the homepage forever (unless they tamper with the properties via the API).

I was able to replicate this on cswiki only, and only with the settings that @Urbanecm_WMF listed. If those are the only conditions under which this happens, I think we can address it on Monday instead of urgently. It is quite rare that many newcomers would choose that exact combination of settings.

Urbanecm_WMF lowered the priority of this task from Unbreak Now! to High.Dec 13 2020, 11:01 AM

As I was unable to figure out other conditions, lowering to high.

We consider this a duplicate. Let's make sure to test this specific error once we fix the original task, T267216.

There is a specific issue here, which is the task @MMiller_WMF mentioned (we have a fix which also speeds things up in the non-anomalous case, but it is a complex change and we probably don't want to deploy it just before the holidays) but also the generic issue that since we have moved task loading to the server side, you get locked out of the homepage completely if it breaks (so you can't just visit the homepage and change your task/topic prefernces). Not sure we have a good way to handle that. We plan to remove most of the complicated logic from cache revalidation, but that still doesn't help if the original query itself breaks. We deal with normal breakage (when the search engine returns an error, for example) but we cannot deal with timeouts. Maybe enough of an edge case that we should just ignore it (once the specific issue is fixed).

What about setting our own timeout, that would be way shorter (10 seconds?
5 seconds?), and if the query takes more than that, just kill it and
display an error? Does that sound doable, @Tgr?


I guess that's technically possible, via Database::setSessionOptions? But timeouts are still DBErrors so it would require some very trigger-happy exception catching.