Page MenuHomePhabricator

[Bug] Still loading a stale Main Page with content service enabled
Closed, ResolvedPublic


While using the beta app this morning, I switched to content service loading* and noticed that it switched back to a stale main page (Josiah Willard Gibbs, the TFA from last Friday, Feb. 11) from what had been the current main page (Chester A. Arthur) when loading from the MediaWiki action API. It remains on Josiah Willard Gibbs after refreshing. I thought this was resolved but it looks like it needs some more work.

*Content service loading is now enabled for the Beta app on 100% of devices, but I was overriding it by setting a restbaseTicket > 100 in the dev settings.

Event Timeline

Mholloway raised the priority of this task from to Normal.
Mholloway updated the task description. (Show Details)
Mholloway moved this task to Needs Triage on the Wikipedia-Android-App-Backlog board.
Mholloway added subscribers: Mholloway, bearND, Dbrant and 2 others.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 15 2016, 3:28 PM

The featured article updates on Main Page are somewhat of a hack on the main site. Basically, all of those featured articles / image of the day etc transclusions are templating the transclusion by date. However, MediaWiki's change propagation system is oblivious to such date-dependent templating, and won't update the page when the date (and thus the translusion) changes. It *does* react to changes in currently-transcluded content or the page itself, and those events are driving RESTBase updates. Since those edits aren't happening all the time, the updates aren't reliably happening whenever the date changes.

To work around this limitation for the desktop site, people have set up a special-case cron job for Main Page, which calls action=purge every 24 hours. To make those hacks work on RESTBase content as well, we could consider hooking into action=purge as well.

GWicke set Security to None.

@GWicke. Do you have a separate ticket for this or do you want to just use this one? This issue is blocking us from moving MCS to production.

Let's use this one as the Android app is the only one currently that is really impacted by this.

Change 270876 had a related patch set uploaded (by Ppchelko):
Hooking into action=purge api call to detect changes with transclusions by date.

I went ahead and implemented a very simple change in RestBaseUpdateJobs extension as I've been in vagrant territory anyway today.

However, when we switch from the RestBaseUpdateJobs extension to change propagation, we would not be able to do the same hack, so we also need to change the EventBus extension to emit an event on purge. This might be either a special page_purged event, or a general resource_changed event that is being discussed now. However, it's not super-logical that a purge leads to a resource_changed event..

Change 270876 merged by Mobrovac:
Hooking into action=purge api call to detect changes with transclusions by date.

GWicke added a comment.EditedFeb 16 2016, 7:27 PM

Thank you, @Pchelolo!

With a bit of luck this *might* be scheduled to go out with the next train deploy, which would put it on the cluster by Thursday.

This is scheduled to go out with the next train deploy. If the train keeps moving to plan, this *might* be live by Thursday.

It will indeed. The patch made it into the wmf.14 branch, which should be on all wikis by Thursday.

I got the current main page content in the dev build today. :) I'll look again on Monday for good measure and then I think we can call it a win.

Still good. :) Should I close this task, or leave it open pending the EventBus change that @Pchelolo mentioned?

@Mholloway Let's wait till gets deployed and then verify the fix actually works in production.

Pchelolo closed this task as Resolved.Mar 1 2016, 8:27 PM

So, the tag is incorrect and the change is in wmf 14, so it's life on all wikis. I've tested it with a simple page that contains a {{CURRENTTIMESTAMP}} template and all works. For main page it also works, as we get an updated content from RESTBase after purging in MW API (judging by changed number of articles).

For EventBus case I've created a separate task: T128510

So, this one can be closed now.