As part of the Services team's goal to implement change propagation, we have the requirement that MediaWiki emit events to the eventbus, for the following edit-related events:
- article creation
- article deletion
- article undeletion
- article edit
- article rename
- revision deletion (suppression)
- file upload
A first set of event schemas documenting the required properties is currently under discussion at https://github.com/wikimedia/restevent/pull/5.
These events will be used for important tasks like hiding deleted revisions, invalidating caches, and replicating changes across datacenters. For this reason, event production needs to be reliable and timely. Best-effort mechanisms like UDP are unlikely to provide the required level of reliability.
To ensure a complete event history in the face of errors, MediaWiki should log event production failures in a way that enables an automatic retry at a later time. Duplicate event submissions will be recognized based on the supplied event ID, a v1 UUID. The producer implementation should also set reasonable timeouts to minimize the impact of failures on the overall MediaWiki request processing.
We can deal with it in two ways:
- Create an extension that will wait for the appropriate hooks to fire
- Integrate event emission in MW-Core
Given that the list of events is currently rather restricted, we could opt for option (1). However, the drawback is the creation of yet another extension that fires off events. Moreover, as the number of tracked events grows, the extension is bound to become quite larger. Additionally, relying on hooks means being compliant and in sync with their API.
Ideally, we'd like to go with option (2). Event creation and emission can be controlled via configuration settings (in LocalSettings.php) and easily turned on/off. Also, putting this into core would mean better code review and greater visibility, which is of utmost importance for events shared within MW event consumers.