@Nirmos can you elaborate on exactly what tags are you expecting?

ChangeTags as described on https://www.mediawiki.org/wiki/Manual:Tags. They are tags that are attached to edits. They can either come from MediaWiki (like visualeditor, HHVM or mobile edit), or they can come from AbuseFilter in which case they are user-defined (well, administrator-defined). Tags are already available in the recentchanges API, if that helps.

@Nirmos The EventStreams system, just like the RCStream system previously, is a public service for storing, buffering and distributing the RCFeed information from MediaWiki's internal RecentChanges system.

I don't mind keeping this task open, but generally when the feed changes in MediaWiki, naturally the output in EventStreams also changes because it is the same data. So I'd suggest declining this task in favour of T24509.

Within MediaWiki itself, some changes are required to make this possible. Right now the way MediaWiki works is that first it creates the revision, then it creates the recent change event, and *then* it adds any change tags. This means that when the RecentChange object is sent to EventStreams, the change tags are not known yet. But a few milliseconds later, by the time any human is realistically looking at the diff or the history page, the tags are indeed displayed.

To make this possible, MediaWiki needs to be altered so that it will fetch the added tags after RecentChange event is created but before it is sent to EventStreams. In addition, all extensions that provide tags (such as AbuseFilter) will need to be altered so that they make use of this new program interface of providing tags together with the edit. Because right now the only way to add change tags for extensions is to wait until after the Revision and RecentChange logic is done. Once we add a way to do this earlier, extensions can be updated to make use of it, then, once all is done, we will have change tags in RecentChange event streams.