OCA / queue

Asynchronous Job Queue
GNU Affero General Public License v3.0
175 stars 451 forks source link

[16.0] queue_job: Autovacuum doesn't clean up sub channels #585

Closed yibudak closed 2 months ago

yibudak commented 9 months ago

To reproduce the error:

1) Add multiple sub-channels under the root channel. 2) Create jobs past the deadline. 3) Run the "AutoVacuum Job Queue" job again in Scheduled Actions.

Autovacuum will only delete jobs with the "root" channel, it will not clean up jobs with sub-channels like "root.1" or "root.2".

Sample odoo.conf:

[queue_job]
channels = root:10, root.0:1, root.1:1, root.2:1, root.3:1, root.4:1, root.5:1, root.6:1, root.7:1, root.8:1, root.9:1

https://github.com/OCA/queue/blob/1ab7b4c477c8a71c837ae68d8b6dc7fdfce24f35/queue_job/models/queue_job.py#L407C28-L407C28

yibudak commented 9 months ago

@guewen

guewen commented 9 months ago

Hi, what do you have in the menu "Queue Job > Channels"? Also, do they match with the content of queue_job.channel fields?

yibudak commented 9 months ago

image image

it's real life example. when we create a channel under a channel, I don't know if it should also appear on the channels screen, in all the work I have done in version 16, only the main channels appear.

guewen commented 9 months ago

Interesting, thanks!

So first thing first, if you create corresponding channels in the UI, you will be able to set a number of days for the cleaning of jobs, per channel, and all jobs will eventually be cleaned.

Now, it shows a possible improvement, during cleanup, we could find the configuration of the closest parent channel in queue.job.channel if no queue.job.channel exists for the job's channel. The solution with an ilike would be too broad as when searching for instance for 'root.%'* it would apply its configuration for all subchannels, including those that already have a configuration.

guewen commented 9 months ago

it's real life example. when we create a channel under a channel

Oh but you mean you created a subchannel on the UI and it doesn't appear? That would be quite another issue 😓

yibudak commented 9 months ago

I need to mention that I didn't create the sub channels within UI, I've just written them in config file. Aren't they supposed to be created on service initializing?

This module works almost perfectly except for autovacuum. As you said "{channel}.%" solution is very broad, this is how I solved my problem for now, but maybe I need to do something different. If you tell me how to do it, I would like to help. Have a nice day.

guewen commented 9 months ago

I need to mention that I didn't create the sub channels within UI, I've just written them in config file. Aren't they supposed to be created on service initializing?

Alright, so as of today, the channels of the configuration file are not created automatically (also without too much thinking, I'm not sure if that'd be desirable in 100% of the cases when applied on multi-db).

So a no-code solution is to create them in the UI :)

Well, if we want a technical solution, what we could do is something like

for channel in queue.job.channel
  search jobs where "jobs.channel" like channel.path.% and not in any channel.subchannels.path
  delete these jobs

Meaning, if you have this in the channels configured on the UI:

The domain would look like: ("channel", "ilike", channel.complete_name + ".%"), ("channel", "not in", subchannels.mapped("complete_name") where subchannels is equal to env["queue.job.channel"].search([("id", "child_of", channel.id), ("id", "!=", channel.id)]). Which means that when cleaning root, it would find jobs for root.2, root.4 etc. but not root.1 nor root.3 as they have their own configuration.

Now, it would be worth checking the performance of this lookup on a high volume of jobs too, vs a simple equality.

github-actions[bot] commented 3 months ago

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.