A few days ago I noticed in Quarry that the actor tables no longer contain any IP users, i.e. SELECT * FROM actor WHERE actor_user IS NULL returns nothing. Of course we can adapt our queries to that, but I couldn't find any announcement or documentation update so I wondered if this is going to be permanent or not.
For what it's worth, this bug breaks the current implementation of FireflyBot's task 11 - notifying authors of drafts on enwiki that they are coming up to the point where they can be deleted. I realise that's a very small matter in the grand scheme of things, and I can rework the implementation around this bug, but thought it worth noting that the bug has "real-world" consequences, even if very tiny ones.
Yesterday an IP user vandalised a page in ruwiki, see . We can see this edit in the "recentchanges" table of Toolforge DB replica: https://quarry.wmflabs.org/query/23027 . Edit with rc_actor=12321013 is vandal edit, edit with rc_actor=4546 is my rollback. You see 2 records for any edit because one of them contains ores=damaging value and another contains ores=goodfaith value.
When I want to know usernames of this users, I request "actor" table with this actor_id. Request select * from actor where actor_id=4546; returns actor_name "MBH", but request select * from actor where actor_id=12321013; returns zero records.
I have a bot in ruwiki, that rollbacks highly likely vandal edits using ORES scores, and since March 6 this bot rolls back only registered users. As far as I can see, an ability to find username of user, who made some edit, was broken on March 6, because when we join recentchanges table with actor one, this returns only records about registered users.
This looks intended https://github.com/wikimedia/puppet/blob/036c84abb076e1ead6a1bf06d29cdaddff1a6357/modules/profile/templates/wmcs/db/wikireplicas/maintain-views.yaml#L272 unless https://github.com/wikimedia/puppet/blob/036c84abb076e1ead6a1bf06d29cdaddff1a6357/modules/profile/templates/wmcs/db/wikireplicas/maintain-views.yaml#L303 or https://github.com/wikimedia/puppet/blob/036c84abb076e1ead6a1bf06d29cdaddff1a6357/modules/profile/templates/wmcs/db/wikireplicas/maintain-views.yaml#L314 matches. Not sure if it would here.
This task is about the actor view. You're looking at three other/different views there: actor_user, actor_logging, and actor_revision.
https://gerrit.wikimedia.org/r/c/operations/puppet/+/668555 was recently committed by @Bstorm for T276124.
I don't think the intent was to remove IPs from the actor view but probably to address a Vuln-Infoleak.
Correct. Filtering the actor table is hard to get right, depending as it does on subqueries to other tables. I tightened it up because some filters were not working. The intent was not to block IP actors. I am looking to find better ways to optimize and filter that view as well. The general logic right now is that it has to have one of a series of possible exposures elsewhere to be exposed in the actor view. I think I have a solution to this issue that would capture both the filtering issue and allow IP actors to show up. I'll put up a patch today.
@MBH the old wikireplica names were forced over to the new wikireplicas this week. I just ran a test and found that SELECT * FROM actor WHERE actor_user IS NULL has loads of results on enwiki there, but not on ruwiki. That seems very strange. I'll dig a bit deeper. ruwiki is on a host that was down for maintenance when some of these fixes were deployed, so it is likely that host needs a re-run of the definitions.