Bug 35462 - "savepoint_0 does not exist" when saving patron
Summary: "savepoint_0 does not exist" when saving patron
Status: RESOLVED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 22.11
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-12-01 13:55 UTC by Magnus Enger
Modified: 2023-12-06 08:54 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Enger 2023-12-01 13:55:34 UTC
When trying to save a new patron, clicking on "Save" sends me right back to the form for adding the new patron, but some of the information I entered is missing (at least firstname and cardnumber). There is no error message displayed. 

I see this in the logs: 

==> /var/log/koha/konaturvard/plack-error.log <==
DBIx::Class::Storage::DBI::mysql::_exec_svp_release(): DBI Exception: DBD::mysql::db do failed: SAVEPOINT savepoint_0 does not exist at /usr/share/koha/lib/Koha/Object.pm line 170
Patron creation failed! - DBIx::Class::Storage::DBI::mysql::_exec_svp_release(): DBI Exception: DBD::mysql::db do failed: SAVEPOINT savepoint_0 does not exist at /usr/share/koha/lib/Koha/Object.pm line 170

The code around /usr/share/koha/lib/Koha/Object.pm line 170 looks like this (in "sub store"):

169     try {
170         return $self->_result()->update_or_insert() ? $self : undef;
171     }

The error "Patron creation failed!" comes from members/memberentry.pl:

424 ###  Error checks should happen before this line.
425 $nok = $nok || scalar(@errors);
426 if ((!$nok) and $nodouble and ($op eq 'insert' or $op eq 'save')){
427     my $success;
428         if ($op eq 'insert'){
429                 # we know it's not a duplicate borrowernumber or there would already be an error
430         delete $newdata{password2};
431         $patron = eval { Koha::Patron->new(\%newdata)->store };
432         if ( $@ ) {
433             # FIXME Urgent error handling here, we cannot fail without relevant feedback
434             # Lot of code will need to be removed from this script to handle exceptions raised by Koha::Patron->store
435             warn "Patron creation failed! - $@"; # Maybe we must die instead of just warn
436             push @messages, {error => 'error_on_insert_patron'};
437             $op = "add";

This happens in two different instances on the same server, but not on other servers with similar setups. 

Koha version: 22.11.10-2 (Debian packages)
OS: Ubuntu 18.04.6 LTS
DB: 10.3.38-MariaDB-0ubuntu0.20.04.1-log

Must be related to bug 26639, I guess.
Comment 1 Jonathan Druart 2023-12-01 14:20:21 UTC
Does it appear after an update?
Comment 2 Jonathan Druart 2023-12-01 14:21:05 UTC
We do no longer support U18 for Koha 22.11 btw.
Comment 3 Magnus Enger 2023-12-01 14:27:36 UTC
> Does it appear after an update?

The issue was reported about month after the upgrade to 22.11, but I think these are fairly low traffic instances, so I'm guessing it wasn't discovered earlier. 

> We do no longer support U18 for Koha 22.11 btw.

Yeah, this made me realize more upgrades are called for.
Comment 4 Magnus Enger 2023-12-06 08:00:04 UTC
We moved the site to a new server (but not the database, which is on a separate/dedicated server), but the problem remains, with the exact same error in the logs that I reported initially. 

The versions are now: 

- Koha 22.11.12-1
- Database: 10.3.38-MariaDB-0ubuntu0.20.04.1-log
- Ubuntu 22.04.3 LTS
Comment 5 Jonathan Druart 2023-12-06 08:21:29 UTC
Do you have plugins installed?
Comment 6 Magnus Enger 2023-12-06 08:33:18 UTC
(In reply to Jonathan Druart from comment #5)
> Do you have plugins installed?

No plugins installed, and plugins are not enabled: 

<enable_plugins>0</enable_plugins>
Comment 7 Magnus Enger 2023-12-06 08:54:14 UTC
Looks like we were running this site with ProxySQL and that was causing the problems. Sorry for the noise, but maybe this bug can serve as a pointer for someone else in the future.