Page MenuHomePhabricator

Flow does not emit recent change event when regular user creates topic
Closed, ResolvedPublic

Description

Edits from Flow are not appearing in the Recent Changes feeds (IRCFeed, EventStreams) when regular users create topics on a new talk page.

By "regular user" I mean anyone that is either contributing anonymously (not logged-in), or is logged-in but not member of a special user group that grants "autopatrolled" status.

Steps to reprodue:

  1. Go to a talk page where StructuredDiscussions is enabled, but no topics exist yet. E.g.: mw:User_talk:rxy/qawsedrftgyhujiko
  2. Click the "Start a new topic" field.
  3. Enter something.
  4. Click the 'Post a new message to ..." field.
  5. Enter something.
  6. Click "Add topic"

Expected:

Topic creation is recorded in recentchanges database, visible on Recent Changes, and also emitted through RC feeds, such as IRCFeed and EventStreams. Easiest is to join irc://irc.wikimedia.org/mediawiki.wikipedia in IRC and observe that no log entry appears for this event.

When performing the same steps as administrator or a staff, then the event does get logged.

Event Timeline

Rxy created this task.Feb 21 2018, 10:14 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 21 2018, 10:14 AM
Rxy updated the task description. (Show Details)Feb 21 2018, 10:21 AM
Restricted Application added a project: Analytics. · View Herald TranscriptMar 6 2018, 6:51 PM

Hi @Etonkovidova. We came across this in Triage meeting. The decision was to have you investigate and then figure out what to do. Can you please have a look? Thanks.

Krinkle renamed this task from Does not appear edits in IRCfeed or Event Stream when non autopatrolled users added comment to Flow does not emit recent change event when regular user creates topic.Mar 7 2018, 12:11 AM
Krinkle updated the task description. (Show Details)
Krinkle triaged this task as High priority.Mar 7 2018, 12:15 AM
Krinkle edited projects, added Regression; removed Analytics, EventBus.

I can reproduce the issue, have clarified the steps to reproduce, and would recommend to treat this as High or UBN. The net cause of this bug and inconsistency, is that our automated patrol systems are blind to a significant portion of contributions that come in through Flow. And from the perspective of monitoring, it is strange that we *do* emit rcfeed messages for contributions by established users, and *not* emitting them for the group that monitoring is built for: Contributions by newer users.

User "Krinkle" creating a topic .
User "KrinkleSock" creating a topic.
Only the topic creation by "Krinkle" has its creation announced on RCFeed.
Catrope raised the priority of this task from High to Unbreak Now!.Apr 10 2018, 5:38 PM
Restricted Application added subscribers: Liuxinyu970226, TerraCodes. · View Herald TranscriptApr 10 2018, 5:38 PM
Etonkovidova added a comment.EditedApr 10 2018, 9:11 PM

Updated comment - the results of testing:

  • Autoconfirmed (not only Autopatrolled) users creating topics will be recorded
  • The server it was checked - irc.wikimedia.org - anon user creating a topic is recorded.
  • On test wiki, anon user creating topic will be recorded correctly also:

Note: Interesting that "creating a topic" event is not directly named as such - RC will have:

When UI RC and Contributions will describe it as a topic creation and mark it with N as a new page.

Catrope closed this task as Invalid.Apr 11 2018, 5:53 PM
Catrope added a subscriber: Catrope.

Closing as invalid because the bug doesn't seem to be reproducible.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptApr 11 2018, 5:53 PM
Krinkle reopened this task as Open.EditedApr 12 2018, 10:53 PM

This is still a problem:

  1. Join IRC server "irc.wikimedia.org", channel #mediawiki.wikipedia
  2. Log out on mediawiki.org, or switch to an account that does not have the "autopatrol" right granted in some way.
  3. Create a topic on any red-link talk page, e.g. Special:MyTalk/Sandbox

Observe that nothing relating to this action was reported in the RC feed channel.

I just reproduced this again a few minutes ago on mediawiki.org with user "KrinkleSock" at User_talk:KrinkleSock/Sandbox.

As a result, a significant amount of Flow actions seems to go entirely unseen by patrollers.

When doing other actions, such as:

  • Creating a similar topic from an autopatrolled account (e.g. staff account), it does get reported in RC feed.
  • When replying to an existing topic from any account, it does get reported in RC feed.
Etonkovidova added a comment.EditedApr 13 2018, 5:14 PM

@Krinkle - yes, you're right. I missed one important piece of the steps you've described (sorry): "Go to a talk page where StructuredDiscussions is enabled, but no topics exist yet. "

On an empty board, a user (not autopatrolled) creates a topic - and it won't reflect in RC feed.

Updated comment: just to emphasize: the board should not have history, it should be a "red link" page (being an empty board with previously deleted/hidden topics won't produce the bug).
I am lowering the priority to High.

Etonkovidova lowered the priority of this task from Unbreak Now! to High.Apr 13 2018, 5:58 PM

I can't reproduce it locally.

My config is

$wgRCFeeds['default'] = [
	'uri' => 'udp://localhost:1338',
	'formatter' => 'IRCColourfulRCFeedFormatter',
	'add_interwiki_prefix' => false,
	'omit_bots' => false,
];

which I believe to be the same as production. I've added logging at the end of UDPRCFeedEngine#send instead of setting up a UDP endpoint.

I did reproduce it on mw.org but I didn't find anything suspicious in the logs around that time.

My only hypothesis so far is that there is some code in the Flow formatter that goes something like this:

if ( user is trusted ) 
  return true
else
  let's load the revision from replica
  oh it doesn't exist (yet), return false

We've seen similar cases in Flow before but I haven't narrowed it down.

Change 460928 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/Flow@master] WIP: Add logging to help debug IRC / RCFeeds reporting

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

JTannerWMF edited projects, added Growth-Team (Current Sprint); removed Growth-Team.
JTannerWMF moved this task from Incoming to In Progress on the Growth-Team (Current Sprint) board.

Change 460928 merged by jenkins-bot:
[mediawiki/extensions/Flow@master] Add logging to help debug IRC / RCFeeds reporting

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

What has been merged is diagnostic code. It should tell us more about the problem after it gets deployed to mw.org tomorrow.

kostajh added a subscriber: kostajh.Oct 1 2018, 8:33 PM

Marking T109549 and T108396 as possibly related.

I can reproduce (on Mediawiki.org, but not locally) that new topic creation isn't emitted for a non-autopatrol group user. (Per the above two tasks, and somewhat confusingly, the event should be emitted as a "reply" rather than "new-topic".)

@Krinkle or @Etonkovidova could you please double-check that the topic creation event is emitted to IRC when you are logged-in as a user in the autopatrol group on mediawiki.org?

@Krinkle also, you marked this with Regression in March 2018 – do you know (roughly) when this functionality last worked correctly?

@kostajh Sorry, I don't remember!

If I recall correctly, during the initial Flow deployment the recent changes feed was not notified at all. This was then fixed at some point, and verified. That leaves quite a long gap for the regression to have occurred. It's also possible that we mistakenly thought it regressed. I believe users did report it as a regression, but it's possible that maybe we just missed this particular use case in the verification process.

However, I'm inclined to believe it was a regression because the use case that is not working is events from unregistered users – which is the vast majority of activity seen in the feed of CVN channels (most activity by registered users is filtered out). If it was the other way around (activity from registered users missing) then it the feed would've mostly looked the same with and without it. But as I understand it, the CVN channels are essentially reporting no activity from Flow right now, whereas presumably they did report some in the past.

OK, thanks for that @Krinkle.

I just tested on test.wikipedia.org and confirmed that new topic creation is emitted to IRC correctly for both an administrator and a newly created user

So that is something, although in itself it doesn't tell me enough to help pinpoint the issue.

kostajh added a comment.EditedOct 2 2018, 5:54 PM

I've noticed that this bug is reproducible on some wikis (mediawiki.org, se.wikimedia.org, kab.wikipedia.org) but not on others (test.wikipedia.org, fr.wikipedia.org).

The commonality with the wikis where it's reproducible is that their wmgFlowNamespaces has Flow enabled for NS_USER_TALK. I'll investigate this further although I don't yet see the connection to this particular bug.

I looked at a profiled request a few minutes ago and think I see where it is failing. Here's the profiled run for the POST request for creating a new topic on a Flow page with no topics: https://performance.wikimedia.org/xhgui/run/view?id=5bd0c4a83f3dfaea44749bcb

It seems like this is where the request runs into issues, and we return false https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/includes/Formatter/RevisionFormatter.php#L213, as seen by https://performance.wikimedia.org/xhgui/run/symbol?id=5bd0c4a83f3dfaea44749bcb&symbol=Flow%5CFormatter%5CRevisionFormatter%3A%3AformatApi --

This means we return false in includes/Formatter/IRCLineUrlFormatter.php#getLine, as seen in https://performance.wikimedia.org/xhgui/run/symbol?id=5bd0c4a83f3dfaea44749bcb&symbol=Flow%5CFormatter%5CIRCLineUrlFormatter%3A%3AgetLine

Looking more closely, in RevisionActionPermissions.php#isAllowed (trace), there's this code:

		// see if we're allowed to perform $action on anything inside this board
		if ( !$this->isBoardAllowed( $workflows[$revisionId], $action ) ) {
			return false;
		}

which then leads to

	public function isDeleted() {
		if ( $this->exists === null ) {
			$this->exists = Title::newFromID( $this->pageId ) !== null;
		}

		// a board that does not yet exist (because workflow has not yet
		// been stored) is not deleted, it just doesn't exist yet
		return !$this->isNew() && !$this->exists;
	}

so, isBoardAllowed() evaluates to false because of !$workflow->isDeleted(). (Source of isDeleted())

Now I need to look at this in my local environment and compare with the stacktrace seen above.

Change 469623 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/Flow@master] Fix recentchanges event not emitted for topic on empty board

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

I was able to reproduce this in the mw-docker-dev environment. Stephane's hypothesis was correct.

In RevisionActionPermissions.php#isBoardAllowed(), there is this code:

		$allowed = $this->user->isAllowedAny( ...(array)$permissions );
		if ( $allowed ) {
			return true;
		}

For a new topic on a blank flow board, $permissions is deletedtext, and we'll return true for privileged users. For unprivileged users, we return !$workflow->isDeleted();, and this ends up as false because we're querying the replica and the title does not exist there yet.

The solution I've submitted is for isDeleted() to query the master DB when in the context of a POST request.

I had half-written a comment suggesting exactly this problem, but then I saw the isNew() check and figured that should catch it. Did you find out why it doesn't?

Change 469623 merged by jenkins-bot:
[mediawiki/extensions/Flow@master] Fix recentchanges event not emitted for topic on empty board

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

Etonkovidova closed this task as Resolved.Dec 5 2018, 10:22 PM
Etonkovidova claimed this task.

Checked in mediawiki - got the same RCfeed output as @kostajh for testwiki - autoconfirmed test user Zilant20 creates a new topic on Flow page:

Would be great to have a clearer indication that a new topic is, in fact, created - RC page will mark it with N: