The NetworkAuth extension would cover the need, though we'd likely want to trim it down a bit for production use.

In T346383#9201814, @matmarex wrote:

By the way, I was very pleasantly surprised to find the wasRedirect() method already existing on DerivedPageDataUpdater. When I was starting this task, I thought I'd have to go on a big adventure just to ferry that piece of data from wherever it is generated to where I needed it, but it was already there! Thanks @daniel, amazing foresight :)

testing of the RESTBase endpoint /data/lists/{id}/entries does not show these additional fields actually being included in the response, although review of the code suggests they should be there. The reasons for this are currently unclear.

If we do need some other combination of SQL and data built around a binary operator, another method would be needed.

Note that there are two options:

1. call the parsoid endpoints exposed by the extension
2. call the page endpoints exposed by core

This could be a problem... To put this in perspective, I dug around and made a histogram of how many different projects are references from individual reading lists.

Some ideas:

In T336693#9179950, @Tgr wrote:

• The RESTBase API depends on (and internally calls) the Action API endpoints

Probably worth emphasizing that a single RESTBase API call might involve Action API calls to multiple wikis.

Looks like the summary isn't actually used by the app, see T346739.

A quick update on the status of the retrospective process: We have concluded the survey and had two listening sessions last week. We are currently evaluating the survey response and deciding whether more listening sessions are needed.

In T226644#9170824, @matmarex wrote:

I found this task while working on T346290. It seems that this has already been fixed once in rMW6feea17779d3: Safer WikiPage redirect functions, then un-fixed in rMWf37ebf4478d2: Introduce PageRecord interface. Let's try to fix it one more time.

Thanks for looking into this @BPirkle! What you write mastly matches my own superficial understanding.

In T336693#9165523, @Tgr wrote:

Not really. The RESTBase API fetches a list of (wiki ID, page ID) pairs from the action API (doesn't matter which wiki), then sends parallel the RESTBase summary endpoint to get the page titles and summaries (I think those are cached internally in RESTBase).

After some discussion, we collectively realized that WikiPage::doPurge will invalidate all relevant parser cache entries, and any resource-change event emitted by it applies to output of parsoid and the old parser alike. This makes it a lot easier to reason about things, we don't have to worry about when things actually get written to the parser cache.

I support this idea. I can't think of a situation where the current behavior would be required. The check can still be bypassed using RevisionRecord::RAW if needed.

In T20493#9148165, @Bugreporter wrote:

A very old idea, T5843: Implement semi-deletion, may also be taken into account when we start to do this (it is not required, but a future schema change may make some reservation to make it easier to happen). Probably I will write a longer comment about this later.

It would be nice to resolve the underlying design flaw that caused this issue. I added a comment to the patch with some thoughts.

The now not-really-stateless back-end service

The idea sounds good, but I have no idea whether it's practical.

re polymorphic modeling: I not that we have the same problem with the ipblocks_restrictions table, where the ir_value field may reepresent a page ID or a namespace ID.

In this context, please note that we are relying on the assumption that there can only be a single active block in some places. In particular, when we want to provide information about the block of a given user, we just look at the most recent block log entry for that user. There is no good way right now to list all active blocks for a user and provide all relevant details about each block, because some of the info is in the block itself, and some is in the respective log entry. If we can have multiple active blocks for a given user, we should have a better way to link block log entries to blocks.

In T335513#9120059, @TheDJ wrote:

Someone should really clarify what we are talking about here.

API servers, endpoints, gateways apps, envoy, internal, external, public, the terminology is used all mixed and inconsistently. Ppl don't know what to expect. To quote discord: "i'm screaming pre-emptively [..] no docs on what's supposed to be the new endpoints"

Parsoid cache warming has been enabled everywhere for a couple of months now.

Resolved by increasing processing concurrency for the cache warming jobs.

We have been using the new backend for a couple of months now. It has been working fine.

In T332435#9118331, @matmarex wrote:

I wouldn't mind that, but the whole project is called IP Masking …

I find the term "IP masking" really misleading, can we rename the task so it talks about "automatic temp accounts" or something?

I like the idea of having DeferredUpdate act as a simple extension of the PHP runtime. However, its current implementation integrates with the per-wiki DB LoadBalancer instance. That logic would need to be factored out of the DeferredUpdate class. I added a comment on the patch with some ideas around that: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/951187/34#message-52b48595021e45b8f6c39f78a1bffd50feb88808

In T337103#9105740, @thiemowmde wrote:

"Classification" in which context?

• From a users perspective there is not really a difference between anonymous (a.k.a. "ip") and temporary (a.k.a. "unnamed"). There is especially nothing the user can do about this. The wiki's configuration dictates which of the two gets assigned to users without an account. So for users the new "temporary account" system is the same as what we previously called "anonymous". In a sense the new system is even more anonymous and I would continue calling it like that.
• From a devs perspective there is not much of a difference between "named" and "unnamed" user accounts. The outlier here is the ip address. This leads to a fundamentally different classification than above.

Sorry if I'm late to the show. But unfortunately the ticket appears to confuse these two scenarios. Or I get it wrong.

In T167246#9098280, @Effeietsanders wrote:

We worked on this at the hackathon a bit and I think we figured it out on our usecase (the first uploader is sometimes in the image table and sometimes in the oldimage table, so you have to use both.

In T167246#9098099, @valerio.bozzolan wrote:

I'm a bit confused now, how is it supposed to get the first uploader of the file now?

Ping @FJoseph-WMF: we need some kind of intake process for this kind of thing...

The experiment of disabling parser cache writes in the parsoid endpoints was successfull: the jobrunner cluster can handle the load of doing all the parsoid re-parses on page edits without the help of the parsoid cluster. To achieve this, allowed concurrency for the parsoidCachePrewarm job had to be increased significantly.

I have not looked at the details, but the only recently merged change that seems potentially relevant is https://gerrit.wikimedia.org/r/c/mediawiki/core/+/935921 by @tstarling.

1. Risky Patch! 🚂🔥

Stalled for now, the plan is to come back to this in a month or two when we have team priorities sorted out.

In T342085#9031409, @Joe wrote:

In T342085#9030615, @daniel wrote:

Ok that explains it. Can't we make restbase just invalidate content instead of also re-generating it?

In T342085#9030518, @Joe wrote:

Correcting myself, the edit that is causing all these pages to be re-rendered is a template edit:

https://commons.wikimedia.org/w/index.php?title=Template%3ANARA-image-full&diff=783237367&oldid=417690735

Again @daniel @ssastry can you imagine a reason why this propagated via restbase but not in the parsoidPreWarm job?

In T341102#9026593, @Tgr wrote:

I wonder if it's possible to just split out "create the main MediaWiki DB" into a separate script, so the main script can be called with the actual wiki as its --wiki parameter.

In T341102#9026363, @Jdforrester-WMF wrote:

The general way is to reserve a window, pull this patch onto an mwmaint server, and try to do the next one on the list (so probably T335216?). Which is… not ideal.

I made a patch that shows how I think this should be approached.
I have no way to safely test this. @Ladsgroup do you have thoughts on how to figure out if this works, without breaking stuff?

Bumping to "high" since this is blocking the deployment of wikifunctions which is scheduled for next week.

The offending code is:

In T341102#9021451, @Tgr wrote:

It would be nice to have a debug option in MediaWikiServices where for each service it stores the stack trace of when it was initialized the first time, and prints that on conflict.

In T155147#9019721, @Daimona wrote:

I was thinking about this, and I think we should allow calls to simple methods like LBFactory::getLocalDomainID for now, but mock their return value. As long as the tests don't make any queries, it should be fine. getLocalDomainID is used a lot in ServiceWiring and other places that simply try to figure out what's the local wiki. I think this is fine, and it would avoid the majority of the failures I've seen.

In T341666#9010186, @Physikerwelt wrote:

When developing the runMulti approach to render formulae in parallel we did assume that the onParserAfterTidy hook would be called once. This seems not to be the case for that example page.

In T341666#9009519, @Physikerwelt wrote:

@daniel Do you think it would be a good idea to increase the number of concurrent requests for formulae (default 50)?