Change Details

There is a need for HTTP-level integration tests for the MediaWik API (the ones from "api-testing" in Node.js) to wait for post-send deferred updates to complete before making certain assertions. This is captured in T230211, which introduced `$wgForceDeferredUpdatesPreSend` and enabled this in DevelopmentSettings.php, which is loaded by the Quibble install used for by the "api-testing" CI job. But, it is also used by all other CI jobs and for developers locally. Disabling DeferredUpdates in their entirety is a significant departure from production behaviour and makes it: * more likely to introduce bugs relating to the use/misuse of DeferredUpdates, or lack of using deferreds, * less likely for devs to experience and report these bugs during development, * harder to reproduce and fix those issues locally. The last point is the one scenari where it'd be reasonable I think to have to turn this off by hand, but that would still pose a notable barrier to discover, learn about, and remember this configuration setting (as opposed to simply assuming it's too complicated to reproduce locally; which I imagine is a more likely outcome for most contributors). ### Proposal Introduce a mechanism by which api-testing can poll for the completion of post-send updates from requests that started prior to "now". From a chat with @tstarling and @aaron, our rough sketch would involve an APCu key that we increment or merge and then poll for it to reach a certain point. Once implemented and enabled in Quibble for the api-testing jobs, we can remove `$wgForceDeferredUpdatesPreSend` from DevelopmentSettings and then remove this internal feature. It seems T230211 is still open, if it this feature is actually not yet relied upon, then we could probably remove it first, and then move the work for the alternate back to the T230211 task.

There is a need for HTTP-level integration tests for the MediaWik API (the ones from "api-testing" in Node.js) to wait for post-send deferred updates to complete before making certain assertions. This is captured in T230211, which introduced `$wgForceDeferredUpdatesPreSend` and enabled this in DevelopmentSettings.php, which is loaded by the Quibble install used for by the "api-testing" CI job. But, it is also used by all other CI jobs and for developers locally. Disabling DeferredUpdates in their entirety is a significant departure from production behaviour and makes it: * more likely to introduce bugs relating to the use/misuse of DeferredUpdates, or lack of using deferreds, * less likely for devs to experience and report these bugs during development, * harder to reproduce and fix those issues locally. The last point is the one scenari where it'd be reasonable I think to have to turn this off by hand, but that would still pose a notable barrier to discover, learn about, and remember this configuration setting (as opposed to simply assuming it's too complicated to reproduce locally; which I imagine is a more likely outcome for most contributors). This came up during [change 771762](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/771762/) ### Proposal Introduce a mechanism by which api-testing can poll for the completion of post-send updates from requests that started prior to "now". From a chat with @tstarling and @aaron, our rough sketch would involve an APCu key that we increment or merge and then poll for it to reach a certain point. Once implemented and enabled in Quibble for the api-testing jobs, we can remove `$wgForceDeferredUpdatesPreSend` from DevelopmentSettings and then remove this internal feature. It seems T230211 is still open, if it this feature is actually not yet relied upon, then we could probably remove it first, and then move the work for the alternate back to the T230211 task.

There is a need for HTTP-level integration tests for the MediaWik API (the ones from "api-testing" in Node.js) to wait for post-send deferred updates to complete before making certain assertions. This is captured in T230211, which introduced `$wgForceDeferredUpdatesPreSend` and enabled this in DevelopmentSettings.php, which is loaded by the Quibble install used for by the "api-testing" CI job. But, it is also used by all other CI jobs and for developers locally. Disabling DeferredUpdates in their entirety is a significant departure from production behaviour and makes it: * more likely to introduce bugs relating to the use/misuse of DeferredUpdates, or lack of using deferreds, * less likely for devs to experience and report these bugs during development, * harder to reproduce and fix those issues locally. The last point is the one scenari where it'd be reasonable I think to have to turn this off by hand, but that would still pose a notable barrier to discover, learn about, and remember this configuration setting (as opposed to simply assuming it's too complicated to reproduce locally; which I imagine is a more likely outcome for most contributors). This came up during [change 771762](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/771762/) ### Proposal Introduce a mechanism by which api-testing can poll for the completion of post-send updates from requests that started prior to "now". From a chat with @tstarling and @aaron, our rough sketch would involve an APCu key that we increment or merge and then poll for it to reach a certain point. Once implemented and enabled in Quibble for the api-testing jobs, we can remove `$wgForceDeferredUpdatesPreSend` from DevelopmentSettings and then remove this internal feature. It seems T230211 is still open, if it this feature is actually not yet relied upon, then we could probably remove it first, and then move the work for the alternate back to the T230211 task.