Uh oh!
There was an error while loading. Please reload this page.
[18.0] queue_job: refactor job acquisition - #866
Conversation
OCA-git-bot
commented
Jan 2, 2026
Hi @guewen, |
265b06e to
8d0b9c9Compareeff0043 to
d6c907aCompared6c907a to
367ab80Compare| " to make this tests work", | ||
| ) | ||
| return job |
sbidoul
commented
Jan 2, 2026
This is ready to review. It can be tested with a small number of workers and a root channel capacity greater than the number of workers and test jobs of duration >= 10 sec. If the test graph has enough parallelism, you will see warnings about dead jobs being requeued (the jobs in state enqueued that are not picked up by workers in due time), but each job should execute only once. Example: The |
hoangtrann
commented
Jan 3, 2026
367ab80 to
69acde4CompareIn this commit we cleanly separate the job acquisition (i.e. verifying the job is in the exepected state, marking it started and locking it) from job execution. We also avoid trying to start the job if it is already locked by using SKIP LOCKED and exiting early. Indeed in such situations the job is likely already being handled by another worker so there is no point trying to start it, so we exit early and let it be handled either by the other worker or the dead job requeuer.
Extract the logic to run one job out of the /queue_job/runjob route. Towards making this logic reusable in other job executors.
69acde4 to
9937ed0CompareTowards making this logic reusable.
sbidoul
commented
Jan 3, 2026
Thanks for the review and testing @hoangtrann ! I added a couple of commits to split out the job execution logic to class method so it is reusable from outside the controller and open the door to experiments such as #871. |
sbidoul
commented
Jan 3, 2026
/ocabot merge patch |
OCA-git-bot
commented
Jan 3, 2026
On my way to merge this fine PR! |
Uh oh!
There was an error while loading. Please reload this page.
OCA-git-bot
commented
Jan 3, 2026
Congratulations, your PR was merged at 48f5707. Thanks a lot for contributing to OCA. ❤️ |

In this PR we cleanly separate the job acquisition (i.e. verifying the job is in the exepected state, marking it started and locking it) from job execution.
We also avoid trying to start the job if it is already locked by using SKIP LOCKED and exiting early. Indeed, in such situations, the job is likely already being handled by another worker so there is no point trying to start it, so we exit early and let it be handled either by the other worker or the dead job requeuer.
Following-up on #859 (comment)
maybe fixes#858