I added a few missing endpoints to the maintainer sheet. I also copied current maintainers to the usage sheet.

I copied this to a google sheet at https://docs.google.com/spreadsheets/d/1rs1aE8x3dgxNdGBXBvh75SMn3NBFshMqkDE-kzqm268/edit?gid=0#gid=0 . I also added some usage/host breakdown info there.

In T415169#11544421, @TheDJ wrote:

In T415169#11543567, @aaron wrote:

[EDIT] I meant to reply to this part separately. I need to look at the original patch more to see what it was trying to accomplish. Is it just trying to handle DivisionByZeroError? Can we not just abort around where the $bitrate is calculated, before that exception is thrown, and return false?

This whole job is unusual, in that it drops the connection after step 1, spends a LOT of time transcoding, and then reinstates the connection and does step 2. This in itself already implies two transaction rounds I think, which probably means we should not leave this to an implicit round of the job runner ?

I checked Turnillo here and here, and the endpoints still looks fine to remove.

In T415169#11543524, @TheDJ wrote:

I think i figured it out... commitPrimaryChanges( __METHOD__ ). but that METHOD is the name for the transaction owner, and in a subfunction, it doesn't match run() which is what the JobRunner assumes $fnameTrxOwner = get_class( $job ) . '::run'; // give run() outer scope

updated the 1229664 patch with those changes and it does seem to work now. It raises the question if we should not simply manage our own transactions with beginPrimaryChanges ? I'm not super familiar with this level of depth of our transaction management combined with that the jobrunner does..

I wonder why WebVideoTranscode::run() has it's own try/catch that doesn't rethrow. This will mean that JobExecuter will still call commitPrimaryChanges(), unaware that the LBFactory is in an error state and a rollback is needed.

In T396807#11520372, @Clement_Goubert wrote:

ATS patch redeployed, it looks ok to me, @aaron can you check and resolve if everything looks good to you?

Here's some raw data to get started (this can go in sorted google doc spreadsheet or something):

In T412530#11475937, @Tgr wrote:

You could just put the username in the path and it would return a 403 if the current user does not match the path user.

In T396807#11503696, @Joe wrote:

In T396807#11498251, @aaron wrote:

We don't need the sandbox to work on www.wikimedia.org, just wikimedia.org. We currently use www.wikimedia.org for rest_v1-wikimedia.json, but I've been thinking about copying that file to standard-docroot and pointing the MediaWiki REST sandbox to that file on meta.wikimedia.org (then deleting the old file later). Basically, I'd like to avoid www.wikimedia.org completely.

There's no wiki associated with wikimedia.org or www.wikimedia.org, so that can't work.

We don't need the sandbox to work on www.wikimedia.org, just wikimedia.org. We currently use www.wikimedia.org for rest_v1-wikimedia.json, but I've been thinking about copying that file to standard-docroot and pointing the MediaWiki REST sandbox to that file on meta.wikimedia.org (then deleting the old file later). Basically, I'd like to avoid www.wikimedia.org completely.

In T165459#11472749, @Tgr wrote:

We could just use WikimediaMessages for this.

In T412530#11455051, @Tgr wrote:

Either we need a REST endpoint for checking whether the user is logged in (the REST version of action=query&meta=userinfo) or we need to get rid of $wgRestAllowCrossOriginCookieAuth and make sure that the Action API and REST API are always in sync wrt CORS support. The latter makes more sense to me but I'm probably missing the reason why it was done this way in the first place.

All stated weeks have passed and the rollout task is closed. Should this task be closed?

The time felt, off so I timed it, and it is off (15 vs 60 seconds)...

time curl -as 'https://zh.wikipedia.org/w/rest.php/v1/revision/90601530/html'
{"httpCode":504,"httpReason":"upstream request timeout"}

On https://zh.wikipedia.org/w/rest.php/v1/revision/90601530/html, I see "The maximum execution time of 60 seconds was exceeded" log entries. Here is some error info from the exception logged on the timeout. Maybe isDiffMarker() is slow, or maybe something broader and the timeout happened to occur in that method.

I ran into this spamming the logs 30 times during a single request while investigating a 504 Gateway Timeout at https://zh.wikipedia.org/w/rest.php/v1/revision/90601530/html .

In T382460#11462012, @BPirkle wrote:

I ended up with a fairly minimal spec that passes validation and includes request and response headers, defined both inline and in reusable components. See this gist:
https://gist.github.com/bpirkle/4e9e64efe9c2c83982bccac9c11865c4

I'm not claiming that's the perfect way to construct these within our specs, but it at least passes validation. Take a look at that and see if it matches up with what you had in mind.

Maybe there is some difference in parser options or hooks for the REST endpoint that makes the ProofReadPage tag hooks act a bit differently?

The description implies that the hyphen appears on regular page views (e.g. https://pl.wikisource.org/wiki/Dziewczyna_bezimienna/Cz%C4%99%C5%9B%C4%87_druga/XVIII), but I don't see it. I do see it on https://pl.wikisource.org/w/rest.php/v1/page/Dziewczyna_bezimienna%2FCz%C4%99%C5%9B%C4%87_druga%2FXVIII/html though (along with page numbers that were not in the regular view). I don't see the hyphen at https://pl.wikisource.org/w/api.php?action=parse&format=json&page=Dziewczyna%20bezimienna%2FCz%C4%99%C5%9B%C4%87%20druga%2FXVIII&formatversion=2 (but the page numbers are there).

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/34977/5/includes/api/ApiPageSet.php#677 , in getRedirectTargets(), seemed to involve keeping a title array (mPendingRedirectIDs) while building up a second title array ($redirectTitles) and then a temporary third title key array and normally empty fourth title key array, then a fifth title array (mRedirectTitles). The prior code was taking items of the first while adding to the second and avoiding the third array.

"This API provides cacheable and straightforward access to Wikimedia content and data, in machine-readable formats." should say something more specific, like "This API provides verification and cacheable rendering of math formulas, in machine-readable formats."