[Koha-bugs] [Bug 28158] Lost items not charging when marked lost from batch item modification

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28158

Jonathan Druart <jonathan.druart+koha at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |critical

--- Comment #4 from Jonathan Druart <jonathan.druart+koha at gmail.com> ---
Investigated a bit here. It's a bit crazy when you read the DBIC_TRACE:

BEGIN WORK
SAVEPOINT savepoint_0
UPDATE `items` SET `cn_sort` = ?, `itemlost` = ?, `itemlost_on` = ? WHERE (
`itemnumber` = ? ): 'CN_1', '1', '2021-05-
24 12:20:47', '1'
RELEASE SAVEPOINT savepoint_0
DBIx::Class::Storage::DBI::mysql::_exec_svp_release(): DBI Exception:
DBD::mysql::db do failed: SAVEPOINT savepoint_0 
does not exist [for Statement "RELEASE SAVEPOINT savepoint_0"]

(then the rollback fails)
ROLLBACK
rollback ineffective with AutoCommit enabled

But my guess is that this is caused by the fork, and more precisely the
following statement:
  $job->progress($i) if $runinbackground;
It is retrieving the session (in the DB is SessionStorage is MySQL), and the
SAVEPOINT does no longer exist.

I confirmed that switching SessionStorage to Memcached and I don't see the
RELEASE error.

The long-term solution is obviously to implement the (new) background job, but
here we need a quick fix.
I don't have much to suggest. Either we remove the transaction (and so the
correct error handling/rollback), or we remove the progress.

We would opt for the latter, removing the transaction is a step backward.

This is definitely blocker for the release.

-- 
You are receiving this mail because:
You are watching all bug changes.