None of the deployed extensions actually write or read page_lang field. The only wiki I managed to find that actually does have the field set is commons, with 136 pages where page_lang is not null - and all of them are main pages.

Change-prop metrics goes through a series of transformations...

If all deployed extesions were updated then it's ready for a patch to hard deprecate the methods.

Waiting for https://gerrit.wikimedia.org/r/c/mediawiki/core/+/665546

@Krinkle you're totally right, caching negatives is wrong in this case. The above patch implements in-process caching for metadata only.

I have *NOT* followed all this discussion closely, but can someone answer as to what extent do these issues translate over to Parsoid?

Resolved long time ago

The problem is, that they *are*. We create the new revision record *before* it is stored in the database, in order to support {{REVISIONID}} on a newly-saved page, etc. And VE stashing/etc also deal with revisions-that-will-be-but-aren't-quite-yet. That's actually a very useful abstraction I'd be very reluctant to give up.

On the change-prop side we already route all video scaling jobs to videoscaler.discovery.wmnet and all other jobs to jobrunner.discovery.wmnet so no change needed there.

cc @daniel as original author.

I think we can go even further and just eliminate the class entirely. It provides no value - it has 3 lines of very simple code in it, no other classes seem to have methods typed with "DBConnectionBase" - zero value.

Rollbacks were deployed, it's not a UBN anymore

Doesn't seem to happen anymore on wmf.36

Oh, I resolved it by mistake. Mostly wanted to CC Cindy since she's working on this area.

Ok, created https://gerrit.wikimedia.org/r/c/mediawiki/core/+/675737 to revert the deprecation.

ParserCache is split on action=render, so none of the action=render pages are usually cached. See T263581 for more details.

Blocker T277795 - should finally be solved by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/674836

In this case we actually have all the data in the row since we've joined it with actor when fetching RecentChange, so we can just instantiate UserIdentityValue directly.

I went over a few instances of this.

Oh right, it's still in the branch in the template. You can use this code https://github.com/wikimedia/service-template-node/pull/148 to see what needs to be done.

@hashar it's a deprecation warning, so it only shows in the logs, no user impact whatsoever. I propose to drop it from the list of blockers, we'll have a look at it this week and try to get into the next week train.

Also, just a note, this is a deprecation warning, not an exception, it's not affecting the users at all, so I'm not sure a UBN train blocker status is fair in this case.

It's possible the RevisionRecord code changed in wmf.36? I'll look into it.

This happened when an editor mistakenly make a redirect like this:

Would it be possible to get EditResult or whatever info is needed into RevisionRecordInserted we need?

Ok. Houston, we do have an implementation problem. I'm fairly certain sending the event from RevisionRecordInserted hook would mitigate the missing revisions problem. However, we don't have the EditResult object there, which is used for rev_is_revert as other revert-related data..

I think I know what the issue is.

Did you update the entire service-template-node or just updated the service-runner? You need this patch to be present in service-template-node: https://github.com/wikimedia/service-template-node/pull/127

Ready for hard for a patch adding hard deprecations.

Status update: we expect https://gerrit.wikimedia.org/r/674131 to completely mitigate the issue once deployed.
There's some followups we would like to make maybe, but they're not required to unblock the train.

What was the reasoning for this back and forth? I can't find much of an explanation anywhere.

I think I know the reason for idoptions.

try harder to look up actors by falling back to master of the ID isn't found. Since an actor with a known ID should always exist, this should be rarely needed, so we could always try it when an ID isn't found. We do something similar in RevisionStore.

It seems like it happens for recent changes for anons who just made their first contribution. Before the patch referenced above we were using User::newFromAnyId which would just instantiate a new User no matter whether it's found in the DB or not, and then upon ->load it will just show the user defaults, while now we hard-crash if the actor is not found in the actor table.

Interesting. Definitely a fallout of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/669946/16/includes/changes/RecentChange.php#1226

Yeah, we've done much progress with converting everything to UserIdentity/ActorStore and thus supporting better cross-wiki users, but haven't touched the File yet, mostly cause it's a very large class hierarchy, so it's hard and didn't qualify as a low hanging fruit.

Ok, I see what's going on.. Sneaky CentralAuth trying to pass around cross-wiki user as a User object... The patch above will not fix it right away, but is a necessary step before we can resolve this one.

Some more log context when this happens:

Sounds good. Not used indeed and IMHO the hook is way too intrusive

Yup, the patch is incorrect. We only need to return UserOdentity when previously User was returned. String for the ip range should still be returned

Yes. Seems like all usages in extensions were removed.