User Details
- User Since
- Jun 24 2015, 10:23 AM (302 w, 4 d)
- Availability
- Available
- LDAP User
- Ppchelko
- MediaWiki User
- PPchelko (WMF) [ Global Accounts ]
Wed, Apr 7
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.
Tue, Apr 6
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.
@Krinkle you're totally right, caching negatives is wrong in this case. The above patch implements in-process caching for metadata only.
Mon, Apr 5
I have *NOT* followed all this discussion closely, but can someone answer as to what extent do these issues translate over to Parsoid?
Fri, Apr 2
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.
Thu, Apr 1
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
Wed, Mar 31
Tue, Mar 30
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.
Mon, Mar 29
ParserCache is split on action=render, so none of the action=render pages are usually cached. See T263581 for more details.
Thu, Mar 25
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.
15:17 Pchelolo: Krinkle: what do you think about this theory: RefreshLinks is a loooong running job, so we establish a master connection when we begin. At some point, we read RecentChanges from a 'recentchanges' group replica - it's well caught up. Then we try to read 'actor' form a replica from another group - that one is not caught up, we fail. The we fallback to master connection, but it was opened looong time ago, and we read repeatable read s 15:17 Pchelolo: napshot - not find anything as well 15:17 Pchelolo: and thus we crash entirely. 15:18 Krinkle: Pchelolo: is ActorStore in master same as this weeks' wmf branch? 15:18 Pchelolo: same 15:18 Krinkle: k 15:20 Krinkle: Pchelolo: yeah, that seems plausible
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.
Wed, Mar 24
@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
Tue, Mar 23
Mon, Mar 22
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.
Fri, Mar 19
I think I know the reason for idoptions.
Thu, Mar 18
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
Wed, Mar 17
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.
Tue, Mar 16
Some more log context when this happens:
Mon, Mar 15
Sounds good. Not used indeed and IMHO the hook is way too intrusive
Sun, Mar 14
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
Mar 5 2021
Yes. Seems like all usages in extensions were removed.