https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33287
--- Comment #5 from Nick Clemens <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
