https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33287 --- Comment #5 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Janusz Kaczmarek from comment #4)
(In reply to Nick Clemens from comment #3)
It may also be this one then: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33019
It's another race condition due to the transaction
Thank you for this hint. However, it seems that the case reported and patched by Aleisha is still only the tip of the iceberg. It seems to me that not only creation a new record causes this issue. Our findings of today are that it happens (i.e. "No job found for id=nnn" in worker-output.log) also when for instance a user renews his checkouts.
What if, in background_jobs_worker.pl, we waited like 500 ms (100 ms?) before calling Koha::BackgroundJobs->find ?
Or maybe, in Koha::BackgroundJob::enqueue, calling in loop ->in_storage after ->store would give us green light to proceed further to call $conn->send_with_receipt ?
I don't like the idea of a delay built in - I think we need to prevent the race condition if we can. It looks like this is the same issue - AddRenewal is called in a transaction - so we need to index after the transaction is committed. Could you open a new bug for that one? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.