Hi Thomas! Am Di., 15. Juli 2025 um 13:18 Uhr schrieb Thomas <tho...@topway.it>:
> > 1) here "Hooks are typically, but not always, invoked synchronously during > the main transaction, while the client waits for a response." -- shouldn't > be rather "while the caller waits" or "where the caller waits" instead of > "while the client waits" if with "client" you mean the hook dispatcher ? > Both, really. If the hook handler (or event listener) is executed synchronously while the caller waits, that typically also means that the client that made the web request is still waiting for a response. That's the case because we only send the web response after the main transaction is complete, otherwise we would not be able to inform the client about errors. If on the other hand we delay invocation of the listener until after the main transaction is complete, we can also defer it until after the response has been sent to the client, to reduce latency. The implication is that listeners can be sure that the original change has been persisted in the database, but it also means that if the listener fails, this will be invisible to the client. This behavior is equivalent to what you would get from a hook handler the schedules a DeferredUpdate, which is already the case for the majority of handlers that perform database updates. 2) here "Events get delivered to listeners via a DeferredUpdate after the > main transaction was successful and the response has been sent to the > client. This clarifies the semantics of extension callbacks invoked as a > result of a change, particularly with respect to transactional context." do > you mean that in case of events the hook handlers cannot anymore modify the > source data before are saved, if that's needed for any reason ? Can you > also clarify more the second part of the paragraph ? > Yes, event listeners cannot modify data before it is saved. Events are notifications about things that happened in the past. If you need to intercept or manipulate an action, you cannot use events, you would just keep using hooks for that, as before. Hooks that allow for the cancellation of actions or manipulation of data will not be replaced by events (though we may look into other ways to make them nicer). With respect to the invocation semantics, the idea is that events guarantee that they are *always* invoked only after the transaction is complete, and only if that transaction is successful. With hooks, there is no such clarity - most hooks are invoked synchronously, but not all - some are invoked in a DeferredUpdated. And this may change without notice, it's not documented or guaranteed. That means that a hook handler that receives e.g. the ID of a newly inserted revision has no guarantee that the transaction won't be rolled back so that revision ID would vanish or might even be re-used for a different revision later. I hope this clears things up a bit. Feel free to edit the manual pages to make them more clear, it's a wiki! -- daniel
_______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
