Sat, Feb 16
The behavior I witnessed here was as described at T207594. It doesn't happen consistently, and does appear consistently fixable by doing vagrant ssh -- sudo service apache2 restart as suggested at https://wikitech.wikimedia.org/wiki/Help:MediaWiki-Vagrant_in_Cloud_VPS#Choose_your_wiki_limbo_state.
Fri, Feb 15
@Jhernandez Looks like this one has a change waiting to roll out when the Stretch migration is complete, so per our discussion earlier this week let's keep it in To Deploy. Then I think it can be resolved.
Thu, Feb 14
Removed the linked patch next to mobileapps, which was unrelated unless I'm missing something.
Wed, Feb 13
For posterity: I was reminded to take a look at this today when the integration-slave-jessie-android instance died as a result of CI hardware failures (https://lists.wikimedia.org/pipermail/cloud/2019-February/000538.html).
I've just started a page at https://www.mediawiki.org/wiki/Extension:WikimediaEditorTasks.
Tue, Feb 12
Mon, Feb 11
Previous discussion of the language selection/fallbacks is available in T184669 and related discussion on Gerrit.
The POTD caption displayed is chosen from among those provided in the POTD template, according to the selection/fallback rules: (1) take the request domain lang, if available, else (2) take English, else (3) take the first available. For today, and for the past several days, only an English caption has existed there, which is surprising, and a change from what we were observing when this API was created. It is not intended or expected that the caption returned will always be in English.
Fri, Feb 8
Trimming the trailing '://' from the site_protocol values seems to fix this. (The docs for the sites table are misleading on this point.) A link can now be created to MWV's enwiki. (A PHP notice is thrown about enwiki being unknown when following the link, but the page loads.)
FYI, my goal is to have the code substantially complete and ready for security review by the end of next week.
Thu, Feb 7
Update: I've managed to get the UI for adding new sitelinks to show by manually adding entries to the sites table for wikidatawiki. Still, when attempting to add one I'm getting an error message stating that the referenced page isn't found:
A page "Foo" could not be found on "enwiki".
The external client site "enwiki" did not provide page information for page "Foo".
Current sites table content (I'm just trying to link to enwiki (en.wiki.local.wmftest.net:8080) for now):
Wed, Feb 6
Actually, upon further reflection, I think I'd go further and say that consistency across DCs is not a requirement here, so long as we are able to store and periodically update the data on a per-DC basis.
Tue, Feb 5
From an architectural point of view I believe RESTBase is behaving as intended here (i.e., by serving a stored response until the underlying content changes), though considering the infrequency of editing, maybe we should disable RESTBase storage in the Beta Cluster (unless Core Platform wants it for their own purposes). Something to chat about in the biweekly sync meeting.
If it's useless to clients, maybe it's best just to take it out.
The tests are passing (and now the test is more appropriate) so I think we can resolve this task. Deciding what to do with the main page case can be followed up with in T215080. I suspect it's too small an edge case for us to worry too much. Will report back if we need any changes upstream.
For posterity, it looks like what happened here is that an edit to the rarely-edited enwiki beta main page triggered a RESTBase summary regeneration, which hadn't happened since before the mainpage summary type was introduced (in Jan 2018).
My best recollection/guess is that it was intended to give clients a hint as to why extracts were being returned empty.