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.

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.

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

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

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.

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.

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()](https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/includes/RevisionActionPermissions.php#L173). ([Source of isDeleted()](https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/includes/Model/Workflow.php#L286))

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