@Legoktm There may be no need for stashing or etags at all if you use the output of https://en.wikipedia.org/w/rest.php/v1/page/Earth/html?flavor=edit. flavor=edit makes it embed all the parsoid annotations in the HTML, which should allow the transform endpoint to turn HTML back into wikitext without the need for stashed state.

The safest pattern for service injection is to use a separate handler for each hook, and to inject only the services needed by that hook.

Calling a hook with the noServices option disables service injection. If a handler for such a hook specifies services, an exception will be thrown when the hook is called.

To me, that line of reasoning makes sense for events as well. Thus, wondering how to name that directory within a component that holds the various handlers.
What do you think?

This would be rather cumbersome in the .map format. GeoJSON allows for a description field that could be abused for this role, but I think it would be a pain to parse.

What would be a good convention for naming the directory that holds the event subscribers?

Thank you!

In T381299#10376789, @Ottomata wrote:

How does this task relate to T378934: Define domain events for page deletion and undeletion?

In T381299#10383200, @Michael wrote:

would/should return:

• The user that performed the purge/changed the restriction, or the user that performed the last edit?
• The user that imported the page or the user that saved the last revision at the source wiki?
• The user that undeleted a revision, or the user that created that undeleted revision, or the user that created the latest revision of the article?

In T381299#10380593, @Ottomata wrote:

purges (see ApiPurge and maybe also PurgeAction).

Hm! Are these page updates? The page (and its revisions) aren't actually changing here, right? It is a materialized view/cached version (html, etc.) of the page that is changing?

Hm, odd. This looks like fallout from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1092772 and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1088321, rfespectively. I can only assume that the test infrastructure was running on an inconsistent copy of the code. If this was a "real" problem, the site would be on fire.

Summary of a conversation with @santhosh on Slack:

We decided to go with the subsciber patter, which provides a natural way of wiring core components. See the ChangeTrackingEventIngress class for an example.

In T379959#10351177, @Ottomata wrote:

DomainEventSubscriber - Uses a DomainEventListenerRegistr(ar|y) instance to automate registering listeners (unchnaged)

I think you mean "Uses a DomainEventSource..." ya?

This all comes back to T20493: RFC: Unify the various deletion systems

See also T364652: Make component boundaries in MediaWiki core easier to discover

It seems to me that https://github.com/qossmic/deptrac may be a good condidate. A first step might be to ensure that code under libs/ doesn't use code outside libs/.

I'm unsure if running a deferred update from a deferred update is a problem or not.

In T380013#10357854, @Michael wrote:

I'm not sure. To me, figuring that out is part of the work that will need to go into the "Investigate ..." subtasks of this task. Probably, that distinction will not be important, but maybe there is some subtlety in one of these hooks that is not obvious during a superficial glance.

Michael wrote on Slack:

Summary of a conversation we had on Slack:

Tagging as high, since it definitly needs fixing, though the impact isn't huge.

This isn't good, but the error rate is relatively low. Tagging MW-Interfaces-Team for tracking, since this is fallout from T376063: Hypothesis WE5.2.3 (Q2 FY24/25): Introduce a system of events and listeners into MediaWiki core.

We already did soem of thes changes. The situation is now:

In T379380#10334772, @Ammarpad wrote:

Hi @daniel Do you consider this a regression or was it intentional change? This is result of and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1069665 and subsequet partial revert.

In T376063#10305402, @Ottomata wrote:

Also

• https://laravel.com/docs/11.x/events

In T379933#10325817, @Nikerabbit wrote:

@daniel Any more info on what level of involvement is expected from us and about the timelines? Asking so that we know how to triage this task.

In T379959#10327898, @Ottomata wrote:

I was playing with Subscriber as a name for this, but IIUC 'subscriber' (as we've defined it) is just sugar for grouping listeners, and a listener is the actual registered function, not thing thing that is registering the method. Subscriber is the class implementing the listener functions, right?

I wonder if a channel concept in the interfaces will be useful. We can default to using $eventType as the $channel, but being able to set channel will allow us to do things like [...] progressive backwards incompatible migrations to new DomainEvent data models.

This would allow you to wire Subscriber classes with a ListenerRegistry, instead of having to pass Subscriber classes the Dispatcher. (If a Subscriber class also wants to Dispatch events, they could wire in a Dispatcher too).

What are the Sink and Source interfaces for?

The reason for having separate interface is that callers typically only need one or the other, rarely both. Interfaces should be structured based on what is used together, not by what is implemented together. That's one of the SOLID principles of OOP design, see https://en.wikipedia.org/wiki/Interface_segregation_principle.
Besides that, I can see special cases where you would implement one without the other. For example, a faux DomainEventSource can be used in a phpunit test to just collect the names of events that a subscriber registers for, to compare that to the list of events listed in extension.json. Similarly, we might have a DomainEventSource for listening to remote events, where the "intake" of the dispatch logic has a form that is different from DomainEventSink, perhaps a polling mechanism implemented in a method like consume( $channel, $maxEvents ). Or we could have a DomainEventSink that dispatches to a bus or queue, and doesn't implement the EventSourceInterface. Or we could refactor and have the implementation of DomainEventSink wrap an implementation of DomainEventSource, so they can both be swapped out separately.

I am closing this as invalid, since the API is working as designed. I filed T380015: Content API (proposal): Allow bots to opt for a lower stash ttl in exchange for a more permissive rate limit instead for discussing improvements around the stahs TTL and rate limit.