The point of my report was to find out if this was something wrong in the WMF-supplied CSS or in the local CSS. An appropriate response might be, "Yes, the folks who maintain the common CSS looked at this and confirm that it is intentional". I think it was inappropriate to close this without giving the CSS folks a chance to look at it.

I'm not familiar with the codebase, so this may be a silly question...

My apologies for commenting on a closed ticket, but there's an enwiki Village Pump thread about this. Could somebody please join that conversation?

BTW, I'm told the same issue exists on the IOS app. I haven't confirmed that, but if it's true, then please feel free to change the title of this ticket to something more generic.

@jhathaway thanks for the response. Yes, I agree with you that trying to make zendesk/cloudmark do something it doesn't want to do is not the way to go, so investigating other systems seems like the way forward.

Is there any progress on this?

I'd be happy to update the on-wiki status message if there's something useful I could say. I've been following the gerrit updates, but I don't know enough about the deployment process to fully understand their implications. Would be be accurate to say, "A fix has been devised and is expected to be deployed this Thursday"?

Reports of this keep showing up, so it appears to be a widespread problem. Would it be possible to roll back Thursday's deployment until a permanent fix for this can be developed?

Another interesting data point from the VPT thread. These three all render in V2022:

• https://en.wikipedia.org/wiki/Module:Clade
• https://en.wikipedia.org/wiki/Module:Biota_infobox
• https://en.wikipedia.org/wiki/Module:Goalscorers

According to this report, the problem also exists on [[Wikipedia:WikiProject Canoeing and Kayaking]]. I was able to reproduce it, but only once in perhaps a dozen tries. As noted by @Xaosflux in that thread, the Special:Prefixindex transclusion happens at the bottom of the page in a navbox.

This is feeling more and more like a cache problem. I've now gone through several cycles of:

Contrary to my speculation on the WP:VPT thread, this does NOT seem to depend on the state of "Enable the Edit Recovery feature" in preferences.

I don't understand why, but as I work my way through the subpages of [[Wikipedia:Featured article candidates/]] on enwiki, almost all of them come up in V2022 mode. Right now I'm looking at [[Wikipedia:Featured article candidates/Markham's storm petrel/archive2]]

This smells like a server-side caching issue. If I load a page that comes up in V2022, I can usually reload it repeatedly and it's still in V2022, but if I do "Hard Reload", it seems to always go back to my normal skin.

This is totally fascinating. When I try that command on my Mac desktop, it also fails in the same way. I obviously don't have the .ssh/wmf key file, but that shouldn't cause the timeout...

Based on https://meta.wikimedia.org/wiki/User:EBarrios_(WMF), it would appear that Eliza Barrios is in charge of the group that runs zendesk. I have emailed her asking for assistance in getting this sorted out. I'm attaching a copy of that mail here:

This is really frustrating. I've apparently been added to the email thread for the zendesk ticket, but I can't access the ticket itself. The email thread includes URLs such as:

Is there some way I can track those zendesk tickets?

@jhathaway This came up during informal discussions between several Ombuds Commission members earlier today.

This topic just came up in another forum and I didn't know what to say regarding status. Could I get an update?

Just to add some additional flavor here, this all started when I set up my account on the ombuds wiki. Lastpass saw a new password being set and updated its entry, but since wikitech and ombuds are both in the wikimedia domain, it got confused and updated the wrong entry. This was further confused by idp also being in the wikimedia.domain. I realize some of the blame can be placed on lastpass, but not all of it, so the WMF side should do as much as it can to make it clear what is happening.

Actually, I said that wrong. 3.7.10 - 3.7.17 are all security releases that came out after 3.7.9. So we're behind 8 security releases.

Let me suggest an alternative which doesn't require any change to the back-end logging machinery. If different logs are contained in different tables, run the queries in parallel, merge the results by timestamp, and present the consolidated result. This is what I do in user code for the "Consolidated timeline" feature of my SPI tools (https://spi-tools.toolforge.org/).

Calling it "Main public logs" doesn't really help, because I have no clue which ones somebody considers the main ones. Seeing all the logs in one consolidated view is often exactly what you want. It's certainly what I want when investigating sockpuppetry or other kinds of abuse. Offering an option to do this seems like a no-brainer. Changing the label may make it (in the words of gerrit 993146) "slightly less bewilderingly wrong", but it's really the wrong direction to be moving.

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

@Dzahn I received no such email. Yes, I checked my spam folder.

Sadly, I didn't get any such number. I got a pretty page with a drawing of a bunch of pastel-colored houses and a message thanking me for submitting my request, but nothing that could be used to trace the progress of that request, i.e. no five or six digit number. The request was submitted a few minutes before 2:37 PM when I updated this ticket; I assume it wouldn't be difficult to check the Zendesk logs from about that time to find the ticket in question.

See also T230700 and T200703

I just opened a zendesk request, briefly describing the problem and linking to this phab ticket. Unfortunately it looks like zendesk doesn't provide any kind of ticket tracking token, so I have no idea how to refer to it.

@jhathaway I'm going to respectfully push back on the idea of prioritizing this as "low". Emergency@ is used to report death threats, people considering self-harm, and well, emergencies. Allowing these to get lost in a spam filter with no human oversight seems like a problem which needs to be addressed.

Related ticket: T348943

Some time ago, when I first started looking at a project which would use ES, I decided I was unable to use the Toolforge ES for exactly the reason @SD0001 describes. I didn't want to ingest my many GB of data only to have somebody delete it all with a single command. Plus I may not want to expose all my data to the world, or even WMF Cloud users.

Any chance this could get prioritized? I originally filed T187417 for this 5 years ago and it's still creating extra work for me almost every day.

Yeah, I can't reproduce it now either. Must have been something transient going on. I'll close this.

I've pinged the developers at [[:en:Wikipedia talk:HotCat ]]

@Jdforrester-WMF why is this HotCat's fault? From the description above, it sounds like the value of wgCurRevisionId being returned is incorrect. Surely a tool like HotCat should be able to rely on that being set properly, no?

@Harej, I disagree with prioritizing this as "medium". This involves silent data loss. That should never be a medium priority. It also sounds like the fix has already been identified (use baserevid instead of basetimestamp) and that fix is probably trivial to implement. So why toss it on the medium heap, which basically means it'll never get fixed?

Wow, yeah, that fixed it, thanks.

@Snaevar I'm reopening this. If after some discussion by all the interested parties it is decided not to implement this feature, that's one thing. I know you disagree with my assessment, and I welcome your input, but I don't think it was appropriate for you to unilaterally close the ticket without discussion.

Interesting. I can still reproduce it here. I normally use Chrome, but just tried this in Firefox 109.0.1 (64-bit) and can reproduce it there as well. I'm not seeing anything exciting in the console:

This feels like it's related to T332799

This is related to T346835

@kostajh I'm not sure what I could usefully share that wouldn't violate CU confidentiality. I also don't think it would be germaine to this ticket. I see two distinct issues here:

Just wondering if anything is happening to this? I'm working another LTA case right now. We list over 400 confirmed socks spanning 2 years. I suspect there's many more that we either haven't found or haven't bothered to tag. This particular LTA has a pattern of creating a new account on some random IPv4 address then switching to a v6 mobile network for editing. If we could block the v6 /36 only for anon or unconfirmed users that would put a big dent in their operation, or at least make it more work for them to roll out new socks. Such a block would have almost no collateral effect. I don't want to fully block the /36 because it would have way too much collateral damage.

The sandbox idea works for me, thanks.

I just got another one of these:

Looking at the suggested workaround instructions:

When I do this:

Thanks for the link. I remember reading that page at some point a long time ago, but didn't remember the details.

Is this documented anywhere?

In case people are not aware of the practical issue here, I'm now getting a:

I agree that this is a bug. I just got bit by the same problem. See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Autosubscribed_to_a_bunch_of_identical_threads_by_mistake?

I would not be surprised if the checkuser extension were sensitive to a similar DOS attack. If not in the PHP backend itself, then likely in the javascript which builds the summary table.

In T338032#8902758, @Dzahn wrote:

I am not sure realtime media helps unless we have actual coverage 24/7 with people in multiple timezones handling these?

There is one case that I know of where a user with enough edits to be ready for consideration for admin rights on the English Wikipedia was determined to be a sockpuppet.

Do we need to store (as opposed to request) client hints for all of the CheckUser-loggable actions, or is there a subset that are most commonly linked to the type of abuse that we use this information for?