[RFC] should jobs ignore deleted records?

[sbidoul]

We have a situation where we create jobs, but sometimes when the job starts the concerned record has been deleted. Such jobs fail.

The use case, is asynchronous execution of costly but non urgent computation. (forecasting in the contract module more precisely).

I'm wondering if queue_job should ignore deleted records, or if that should be handled at the application level, and how?

@lmignon @guewen cc/ @sbejaoui

[guewen]

This is indeed a pretty common issue and I think in most if not all cases we'll want to ignore deleted records. Until now, I always assumed it was to be handled at application-level, but that's a nice discussion to open.

Some thoughts. We can have recordsets in different arguments:

@job
def myjob(self, other_record):
    print(self, other_record)

In most of the cases we want:

@job
def myjob(self, other_record):
    if not self.exists():  # a generic condition would need to compare self._ids and self.exists()._ids to still support @api.model
        return
    print(self, other_record)

But we'll probably want to handle this only for self and leave other_record's handling at the developer's appreciation, and maybe give an option to opt-out of this behavior.

edit: more thoughts: better in fact to apply .exists() on every recordset when retrieved from the json args. Though only an empty self when it was not empty before should discard the job.

[sbidoul]

@guewen something like #141?

[guewen]

@sbidoul that could be a way, if we want to handle it for all the args and keyword args we could handle it at a lower level during the field deserialization:

queue/queue_job/fields.py

Lines 62 to 66 in 490f246

	if type_ == 'odoo_recordset':
	model = self.env[obj['model']]
	if obj.get('uid'):
	model = model.sudo(obj['uid'])
	return model.browse(obj['ids'])

[lmignon]

@guewen @sbidoul I agree that we should ignore deleted records by default at all levels (self and args/kwargs). I also think it could be a good idea to have an option to opt-out this behavior.

[github-actions]

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.