Bug 36900 - Job errors should be stored on a separate location
Summary: Job errors should be stored on a separate location
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 35092
  Show dependency treegraph
 
Reported: 2024-05-21 00:07 UTC by Tomás Cohen Arazi
Modified: 2024-05-21 13:14 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomás Cohen Arazi 2024-05-21 00:07:04 UTC
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.
Comment 1 Tomás Cohen Arazi 2024-05-21 00:07:52 UTC
Right now it is the job's responsibility to manipulate the `data` column adding error messages. Which seems weird.
Comment 2 Jonathan Druart 2024-05-21 06:56:55 UTC
(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.
Comment 3 Julian Maurice 2024-05-21 07:27:58 UTC
What do you think about a background_jobs_logs table ?
With columns such as: background_jobs_logs_id, background_jobs_id, timestamp, level, message.
Comment 4 Tomás Cohen Arazi 2024-05-21 12:14:10 UTC
(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.
Comment 5 Tomás Cohen Arazi 2024-05-21 12:14:38 UTC
(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.