In T333606#9748207, @ABreault-WMF wrote:

There hasn't been a spec bump in Parsoid since around June 2023 when that was posted. This would only happen when the cache contained the previous version after a spec bump. The parser cache expires in 15 days? anyways.

How will this be kept in sync with tables.json in MW core and extensions? Would it be possible to periodically scan for disrepancies?

In T333606#8924625, @Arlolra wrote:

The following graphs show rerenders due to 'not-parsoid-default',

In T362850#9746323, @Tgr wrote:

I'd deprecate "post", and pass "body" parameters to the BodyValidator (which is based on the mime type and could be a FormDataBodyValidator, so form data support is easy to preserve although old code would have to be updated).

The OAuth 2 spec does make use of application/x-www-form-urlencoded for some endpoints, no form data though I think.

In T362850#9745259, @Tgr wrote:

The concept of "post" parameters makes more sense once you realize their name is a reference to $_POST, not POST bodies in general. So in that sense extending them to JSON fields would actually be more confusing.

Given that form data handling is not that useful in the REST API in general, maybe just deprecate post parameters for that API entirely?

Quick summary of a conversation with Timo:

• the primary protection mechansim should eb "off per default, enabled on internal cluster"
• to prevent 3rd frmo accidentially making this endpoint public , there should be a second line of defense, like a list of IPs
• signing requests, like SpecialRunJobs does, is a good mechanism as well. As long as the signature is created by MW, it's easy. It's inconvenient to try and generate a signature outside MW.
• relying on the host header for picking the wiki that needs to process a job should be fine, but we nede to actually start setting this header in changeprop
• we can probably just use the RunSingleJob REST enpoint that exists in the EventBus extension. Should we move it into core? 3rd parties are very unlinkely to ever need it.

In T359364#9722421, @daniel wrote:

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.

Alternatively, we can just look at year, month and day as three integers, and calculate the output based on that. In that case, we would drop suppor for weeks.

In T219397#9737491, @Tgr wrote:

In T219397#9714526, @daniel wrote:

That would mean July 1 was one month ago compared to July 31, and July 31 was one month and one day ago compared to August 31. A bit weird although not terrible. And it should work for locales with non-Gregorian calendars as well, which all have similar month lengths.

Notes to self:

• Why do we need rpc/RunSingleJob.php, if EventBus already has a REST handler for RunSingleJob?
• rpc/RunSingleJob.php uses the "database" field in the body to pick the wiki. Why are we not using the Host header, like we do for all other entry points?
• @akosiaris sais the host header should be present, per https://github.com/wikimedia/mediawiki-services-change-propagation/blob/master/config.jobqueue.wikimedia.yaml#L51
• @Jgiannelos found the job runner deployment charts: https://codesearch.wmcloud.org/search/?q=jobrunner_uri&files=&excludeFiles=&repos=

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