Page MenuHomePhabricator

actor_user = NULL (IPs) missing from Wiki Replicas
Closed, ResolvedPublic

Description

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.

Event Timeline

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 [1]. 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.

[1]: https://ru.wikipedia.org/w/index.php?title=Летнее_время&action=history

JJMC89 renamed this task from IP users in replica actor tables to IP users missing from the replica actor table.Mar 8 2021, 3:02 AM
MBH triaged this task as Unbreak Now! priority.Mar 8 2021, 3:06 AM
MBH renamed this task from IP users missing from the replica actor table to It's impossible to discover IP of unregistered user who made an edit, using Toolforge DB replicas.Mar 8 2021, 4:05 AM
RhinosF1 renamed this task from It's impossible to discover IP of unregistered user who made an edit, using Toolforge DB replicas to actor_user = NULL (IPs) missing from Toolforge Wiki Replicas.Mar 8 2021, 7:27 AM
RhinosF1 added a subscriber: RhinosF1.

Renaming task to actually describe the issue rather than the impact.

Majavah renamed this task from actor_user = NULL (IPs) missing from Toolforge Wiki Replicas to actor_user = NULL (IPs) missing from Wiki Replicas.Mar 8 2021, 7:32 AM
Majavah added a subscriber: Majavah.
JJMC89 added subscribers: Bstorm, sbassett, JJMC89.

This looks intended [...].

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.

This looks intended [...].

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.

Change 669888 had a related patch set uploaded (by Bstorm; owner: Bstorm):
[operations/puppet@production] wikireplicas: expose actor_user = NULL (IPs) again in actor view

https://gerrit.wikimedia.org/r/669888

I have confirmed that patch will fix this. Hoping for a review from someone on it.

Change 669888 merged by Bstorm:
[operations/puppet@production] wikireplicas: expose actor_user = NULL (IPs) again in actor view

https://gerrit.wikimedia.org/r/669888

Change 670008 had a related patch set uploaded (by Bstorm; owner: Bstorm):
[operations/puppet@production] wikireplicas: depool labsdb1010 for view changes

https://gerrit.wikimedia.org/r/670008

Change 670008 merged by Bstorm:
[operations/puppet@production] wikireplicas: depool labsdb1010 for view changes

https://gerrit.wikimedia.org/r/670008

Bstorm claimed this task.

That should have done it.

@Bstorm we have this problem again, request SELECT * FROM actor WHERE actor_user IS NULL returns no data.

That's very strange... I'm not aware of any changes to the views any time recently. Which wiki? @MBH do you have a quarry link I can try or something?

@Bstorm https://quarry.wmflabs.org/query/23027 , plus my ORES-using-vand-rollbacking bot stuck and rolls back only registered users last 1.5 days again.

@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.

Yep, that theory was it. Works now. Sorry about that quirk.