I wrote a proposal for an alternative to deprecating "post" parameters: T362850: REST: clarify the relationship between "post" and "body" parameters

This may not have been such a good idea afterall. I'll think about it some more before re-submitting.

In T340185#9064841, @BPirkle wrote:

In T340185#9061276, @Tgr wrote:

FWIW the REST API uses MediaWiki\Rest\Validator\ParamValidatorCallbacks

Yeah, in fact there's this fun little comment in ParamValidatorCallbacks.php, in the getValue function:

		// @todo Should normalization to NFC UTF-8 be done here (much like in the
		// action API and the rest of MW), or should it be left to handlers to
		// do whatever normalization they need?

@Reedy On the patch you expressed concern about the size of the JS code that we'd ship. Do you have an idea of how we could reduce it?

The layout of the page is less then perfect. For now, I was hoping to have it merged and enabled on beta and testwiki, so we can try it out. The CSS could definitly use some TLC from an expert, I just slapped it in there...

This task covers client-side code for a variety of APIs owned by different teams. Perhaps it would make sense to split it into separate tasks, each covering the client side code for functionality owned by a given team.

This task covers client-side code for a variety of APIs owned by different teams. Perhaps it would make sense to split it into separate tasks, each covering the client side code for functionality owned by a given team.

I think we can simply assume that a month is 30 days long. That way we end up with 12.2 months in a year, but that still rounds to 12.

Should be simple enough these days, by overwriting finalSetup() in the maintenance class. One can then use $this->getOption to ge the value of a command line option, and $settingsBuilder->getConfig() to get the configuration, and $settingsBuilder->overrideConfigValue() to set the new value.

What I am trying to figure out right now is how we can send API requests to the correct domain. rpc/runSingleJob.php looks at the "databas" field of the payload and then uses MWMultiVersion::getMediaWiki to initialize the correct wiki. If we use the RESt API, we have to use the Host header instead. Or we send some other header, like X-Wiki-Name, that gets interpreted by MWMultiVersion::getMediaWiki.

In T175146#9711987, @Krinkle wrote:

@daniel Is the REST API safe to remove from the EventBus extension? We may want to do that first.

In T362480#9712034, @Krinkle wrote:

There is also ResourceLoader, which refers to its resource bundles as "modules".

In T362480#9711760, @Tgr wrote:

"Modules" is a somewhat unfortunate name IMO, given that the action API calls single endpoints "modules".

In T175146#9710653, @Krinkle wrote:

@daniel Are you thinking about IP subnets as protection mechanism because you prefer it, or because you think it's what we use today? Of the 5 job runners in the task description, number 4 used this mechanism. However that one (runJobs.php) has not been in use for several years. I've updated the task description to clarify this.

Ok, seeing errors now, and filing tickets: https://logstash.wikimedia.org/goto/8cf77667ebb17ba5a1ea8190d48f27f1

In T356157#9703984, @matmarex wrote:

Are we sure entries in this channel would be logged in production? I thought new channels have to be added here first: https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/4536766ecc16f0950fccc417bf749b7d485d0708/wmf-config/InitialiseSettings.php#2076

1. Risky Patch! 🚂🔥

I replied on the other ticket, see T335512#9701882

Cross-linking for reference: T362187: REST HTML endpoint returning 500 for the first 3 - 5 calls for several pages

The pages you list are all from projects with relatively little edits and traffic, which makes it more likely to encounter uncached pages.

The new endpoint has a different cache regime. It is relying on MediaWiki's internal parser cache, which only contins pages that have been updated (directly or indirectly) in the last three weeks. Accessing uncached pages can be fairly slow. Typically, large and complex pages are also updated a lot. But of course, that is not always the case.

I am not able to reproduce these errors. When I put the URLs from the error messages into my browser, they seem to work fine (if somewhat slow).

Quick note: the task description is somewhat outdated, update to come

In T357532#9696547, @Urbanecm_WMF wrote:

...my main question is how would the schema converter do the conversion between schemas. I was thinking about having an upgrade/downgrade callable somewhere and call it from the converter, but I'm unsure on what that somewhere is. Do you have any thoughts on that, please?

Quick summary of my thoughts after talking to @Daimona just now:

• It would be nice to have a narrow interface for getting endpoint URLs for other wikis. There are several use cases for this, e.g. redirecting to file pages on commons or listing interwiki links.
• A basic (wmf centric) implementation of such a mechanism would not be very hard, perhaps a week of work between the two of us.
• Making this work "right" gets us back to T113034: RFC: Overhaul Interwiki map, unify with Sites and WikiMap, wich we have been procrastinating on since 2015.

Some thoughts on the topic of schema migration (without having looked at the code structure):

• The JSON should contain a version marker in a meta-field - we could include a full schema URI in "$schema", or use something like "$config-version".
• The provider interface gets a getSchemaConverter() method that takes a source version and target version.
• The provider interface gets a loadSchema() method that takes an optional version parameter.
• The schema class defined a constant that specified the version (and/or schema URI).

Quick brainstorming:

In T361840#9689341, @Atieno wrote:

This might be obvious but just noting it here so it's part of these notes "Path parameters are preserved when generating redirects." includes both param value and order i.e

Nothing in the log since Feb 15.

This needs discussion with someone from service ops about how to safely expose RunSingleJob as a REST endpoint, so it does not become publically accessible.

Nobody has been asking for more documentations, so I think this is done.

Pinging @tstarling , because Eximer

On the subject of trailing slashes: