There should be a `last_error` column for storing the error. I picked that name, thinking of the 'retry' use case. But if it got implemented, we could want to have a separate table for different errors through a job's lifecycle.
Right now it is the job's responsibility to manipulate the `data` column adding error messages. Which seems weird.
(In reply to Tomás Cohen Arazi from comment #1) > Right now it is the job's responsibility to manipulate the `data` column > adding error messages. Which seems weird. Weird but more flexible. We could however add more helpers to Koha::BackgroundJob to not need to deal with data directly. But personally I don't think we need a separate DB column for that. We could have a test on store to make sure data is a correct JSON encoded string.
What do you think about a background_jobs_logs table ? With columns such as: background_jobs_logs_id, background_jobs_id, timestamp, level, message.
(In reply to Jonathan Druart from comment #2) > (In reply to Tomás Cohen Arazi from comment #1) > > Right now it is the job's responsibility to manipulate the `data` column > > adding error messages. Which seems weird. > > Weird but more flexible. We could however add more helpers to > Koha::BackgroundJob to not need to deal with data directly. But personally I > don't think we need a separate DB column for that. I've been thinking of the use cases we have, and I think a `feedback` column that doesn't mix the job data with errors or feedback of any kind is better than mixing the job parameters with feedback on the same data structure.
(In reply to Julian Maurice from comment #3) > What do you think about a background_jobs_logs table ? > With columns such as: background_jobs_logs_id, background_jobs_id, > timestamp, level, message. I didn't think of 'level', but this is were I ultimately was headed to.