From a Data Products perspective, we don't seem to consume mediawiki.user-blocks-change in any Airflow DAGs, so this change doesn't seem to have cascading effects. We do still have to deal with T348252 from a Dumps 2.0 perspective, but that was known work before this ticket.

Table wmf.mediawiki_user_history does expose user blocks, but it exposes them in an array already. It does not expose expiration dates. As per the technical details of this new Multiblocks feature, there are significant database schema changes. But a cursory look at the code that generates wmf.mediawiki_user_history suggests that no changes would be needed since the job consumes block logs from the logging table rather than going directly to the ipblocks table.

@xcollazo we are all clear on Dumps 1 also?

@VirginiaPoundstone Is there any action that CommTech needs to take at this stage? Just wondering if we can remove from our backlog or if we need to create a ticket

@JWheeler-WMF EventBus extension uses the BlockIpComplete hook. If there are no changes to this hook API, then there are no changes needed for EventBus or the mediawiki.user-blocks-change stream. However, I'd assume that to accomodate Multiblocks feature, the hook will need to be changed to represent the multiple expiration dates of the different blocks.

If the hook interface and semantics are changed, then EventBus and the mediawiki/user/blocks-change schema will need updating to use the new hook.

So I guess the q is: Will the BlockIpComplete API change, and if so, how? :)

Thanks!

In T356597#9535953, @VirginiaPoundstone wrote:

@xcollazo we are all clear on Dumps 1 also?

All clear. None of this is used by Dumps 1.0.