In T351685#9357602, @Tgr wrote:

(We could also maybe just flip the www.wikisource.org -> wikisource.org redirect. All of our other multilingual wikis on a second-level domain, like mediawiki.org or wikidata.org, behave that way. Granted wikisource is the only wiki which has both a generic version and a language family, so maybe there is some special reason I'm missing that applies to it.)

It looks like that edit was imported, per https://de.wikipedia.org/w/index.php?title=Benutzer:Shi_Annan/Abigail_Becker&action=history

For good measure. I manually looked at the portal (help) page, and added some checks for format=xml and format=php and some CSP assertions for parse/opensearch. So far so good.

On https://commons.wikimedia.org/wiki/File:Harku_m%C3%B5isa_park.JPG, I see both versions have timestamp 2013-06-05T14:45:37 , so this is the same bug as the ambiguous timestamp bug.

In T328872#10873913, @Ladsgroup wrote:

I'm not sure where would be a good place to put this but I think I found something weird with how uploads work. I tried uploading a very small svg file in testwiki with excimer. 857ms was spent in the swift area but very little of it to do the upload. Let me break it down: https://performance.wikimedia.org/excimer/profile/03c4168ac24eb7eb

So...it looks like mediawiki-config needs some tweaks under docroot. wikimedia.org redirects to www.wikimedia.org which has the wwwportal docroot, not the wikimedia one. I think I'll just make an api/restbase_specs dir under wwwportal and move rest_v1-wikimedia.json there.

FYI, I suspect the "Age" oddity is a mix of https://github.com/varnishcache/varnish-cache/commit/cff50548b9633b676d71fc82c9103b368807e9a3 (normal behavior) and some clock skew among servers.

Anyway, aside from that pre-existing "age" header anomaly, I was able to update the script to check that the opensearch API is cached for logged out users on subsequent requests with the same cache busting parameter value. It also checks for no caching when logged in (cookie or bearer token), checking for x-cache-status=pass (which avoids the >0 issue with age and also the ambiguity of it being >0 but rounded to 0).

I noticed an oddity of sometimes getting "age: 2" or "age: 1" from test2wiki action=parse responses for logged in user, so I tried testwiki and got the same, even with cache busting parameters (that affect the response since api.php points out that the parameter is not recognized). I can do this with all sorts of api actions really, even as an anon.

In T406724#11291602, @Bawolff wrote:

I was under the impression that user_touched was not updated on login. Maybe I'm mistaken but a quick look through the code I don't see anything that would set it on login.

In T406724#11255660, @Tgr wrote:

In T406724#11255547, @Ladsgroup wrote:

I do agree also watchlist should not have this limit specially because we want Special:UnwatchedPages and so on to be reflecting the reality.

Although for that purpose specifically, you could also just dynamically filter out users by user_touched. I think FlaggedRevs does that for its pseudo-watchlist of unreviewed changes.

In T406599#11280844, @Clement_Goubert wrote:

50% traffic split for test2wiki action API is merged and working. It will be deployed completely in the next 30 minutes.

In some cases, it was a bit tricky for me to tell what components where just existing one versus new ones. I also wasn't totally sure which components where meant to have class hierarchies and which would be methods. A few comments, by component:

Looks like PageHistoryCountHandler should check the from/to revisions getPage() and produce a LocalizedHttpException instead of letting things fail in RevisionStore, which spams the exception logs.

Moving this off the sprint, since it was added due to some kind glitch.

Re-opening for now so it shows on the sprint board.

Everything passes and I don't see any remaining issues.

Ideally, complicated things like LocalFile::recordUpload3 would not be use onTransaction* methods. That method was meant for simple callbacks witha few direct write queries, unlock queries, cache purges, key/value store sets, and such.

I noticed an oddity in EnchangedChangesList in recentChangesBlockGroup():

Is there a specific use case that motivates this or is it a matter of general completeness/utility.