Page MenuHomePhabricator

API integration tests need a way to flush the job queue.
Closed, ResolvedPublic3 Story Points

Description

In order to be able to assert the outcome of some actions, API integration tests need to be able to cause the job queue to process all pending jobs. This can be done via the internal Special:RunJobs endpoint.

This serves a similar purpose as T230211: Enable API integration tests to ensure that GET requests will always see the effect of previous POST requests., but is technically orthogonal. During testing, most tests should probably wait for DB replication, but most tests don't care about the job queue.

On the other hand, the test suite should not leave the target wiki with a large number of unprocessed jobs either. We may want to provide a way to truncate the job queue as well, maybe using a maintenance script.

Event Timeline

daniel created this task.Sep 2 2019, 2:31 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 2 2019, 2:31 PM
WDoranWMF set the point value for this task to 3.Sep 4 2019, 6:28 PM

Change 534844 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/core@master] SpecialRunJobs: optional output stats, including queue size

https://gerrit.wikimedia.org/r/534844

daniel claimed this task.Sep 6 2019, 4:43 PM
daniel moved this task from Ready to Doing on the Core Platform Team Workboards (Purple) board.

Change 530642 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/tools/api-testing@master] Trigger jobs when needed

https://gerrit.wikimedia.org/r/530642

Krinkle added a subscriber: Krinkle.EditedSep 7 2019, 3:51 PM

Does the test have access to the IP directory? If so, it might be simpler to run php maintenance/runJobs.php --result json instead.. By default it continues until all jobs have finished executing. The reached property can be used to decide whether additional rounds are needed (eg. if it stopped early for other reasons).

A similar need has come up in the wdio Selenium browser tests, where I plan to give this a try as well, but if you can confirm or rule it out first, that'd help :)

daniel added a comment.Sep 7 2019, 8:43 PM

Does the test have access to the IP directory? If so, it might be simpler to run php maintenance/runJobs.php --result json instead.. By default it continues until all jobs have finished executing. The reached property can be used to decide whether additional rounds are needed (eg. if it stopped early for other reasons).
ever
A similar need has come up in the wdio Selenium browser tests, where I plan to give this a try as well, but if you can confirm or rule it out first, that'd help :)

It may or may not be possible to run maintenance scripts, depending on the context. In general, the assumption is that mediawiki is running on a different host (or in a separate container). It may be possible to ssh into the container, but this all sounds more complicated than just calling Special:RunJobs.

Is the "reached" property reliable? That is, would it never cause the client to prematurely continue, even if there are still jobs pending? Is it more reliable than asking for the queue size?

Krinkle added a comment.EditedSep 10 2019, 6:04 PM

Is the "reached" property reliable?

I believe so, yes. Querying the queue size will probably be the same in most cases. But "tried to pop more and got nothing" I think most directly represents the logical intent. Being equivalent to what would happen if you were to try running jobs again. Querying the queue size might be subject to caches or race conditions etc, might be fine in simple set ups.

"reached" can be (or is?) exposed through the Special page as well. They use the same JobRunner class.

It may or may not be possible to run maintenance scripts, depending on the context. In general, the assumption is that mediawiki is running on a different host [..] more complicated than just calling Special:RunJobs.

Agreed. Might need to set up secret keys which then need to be put into or pulled out from LocalSettings and exposed as ENV variables perhaps. Certainly doable. We tried this but found it messy in WDIO to duplicate all that logic in JS due some convenient PHP builtins not being available in JS. If we already assume access to the same ENV variables and LocalSettings, figured shelling out was easier.

Change 534844 merged by jenkins-bot:
[mediawiki/core@master] SpecialRunJobs: optional output stats and status.

https://gerrit.wikimedia.org/r/534844

Change 530642 merged by Clarakosi:
[mediawiki/tools/api-testing@master] Trigger jobs when needed

https://gerrit.wikimedia.org/r/530642

daniel closed this task as Resolved.Fri, Sep 20, 10:22 AM