When registering with a DomainEventSource, listeners should be able to specify a mode of dispatch. Initially, two modes are supported:
In the future, we may add more dispatch modes, e.g. fully async, like jobs.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| DomainEventSource: introduce dispatch modes | mediawiki/core | master | +161 -123 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| In Progress | daniel | T376063 Hypothesis WE5.2.3 (Q2 FY24/25): Introduce a system of events and listeners into MediaWiki core | |||
| In Progress | daniel | T379775 DomainEventSource: support different dispatch modes |
Change #1090555 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):
[mediawiki/core@master] DomainEventDispatcher: instrioduce dispatch modes
In the future, we may add more dispatch modes, e.g. fully async, like jobs.
I have been reading the Broadcasting Events and Remote events section of the design doc, and trying really hard to envision how this is going to work.
I haven't come up with anything satisfying, everything is very awkward. Let's chat and/or I'll try to find some time soon to summarize thoughts.
I am currently exploring what it would be like if the interface completely decoupled publishing events from subscribing and invoking their listeners.
DeferredUpdate mode and also an 'async' mode both sort of work like this. The difference is that DeferredUpdate's queue has the full listener+event callback closure, whereas the async/bus queue would only have the event. Figuring out which listeners to call for an event would have to be a concern of the subscriber/consumer side of things.
Not sure if this will make sense...but I'm trying!
@Ottomata I just filed T379935: Explore a mechanism for publishing domain events to an event bus, I think your comments would better fit there.... want to copy/move them?
I think publishing is different from dispatching to local listeners, event from fully async dispatching to local listeners. One key difference is that listeners that register for async dispatch still execute in the context of the local wiki. It's conceptually different from receiving events from a different wiki or service.
Yes, will move.
And I think you are probably right. I was hoping we could make the interface for subscribing remotely the same / similar. We might be able to...but do we want to? TBD.
@daniel, if IMMEDIATE_DISPATCH is the default mode, then how much value is there in supporting COMMIT_DISPATCH?
IIUC, COMMIT_DISPATCH is just some sugar on DeferredUpdates, yes? Would it be simpler to just let people register a $listener that uses DeferredUpdates itself?
Or, maybe the reason is the automatic passing of $dbProvider?
I really liked the idea of supporting different modes somehow, but after thinking about how we might do an async/bus mode in T379935#10323299, I don't think we'd do so by implementing BUS_DISPATCH as a supported mode, but as a different DomainEventDispatcher instance, as you suggested. So if we don't need that, then maybe we don't need 2 the 2 modes?
Change #1090555 had a related patch set uploaded (by Ottomata; author: Daniel Kinzler):
[mediawiki/core@master] DomainEventDispatcher: introduce dispatch modes
I updated the task with what I hope is a helpful correction: The dispatch mode is being introduced to the DomainEventSource interface (not DomainEventDispatcher).
Please revert if this is incorrect.
Estimated 3 points, mostoly for discussing/defining semantics. The implementation is straight forward (and already compelte).