Deleting Metarecords breaks hold interfaces

Bug #1441301 reported by Blake GH on 2015-04-07
56
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

12.04
EG 2.7.0
PG 9.2
OSRF 2.4

This is the same as:

https://bugs.launchpad.net/evergreen/+bug/937789

but with Metarecords instead of parts. If there is a hold on a metarecord that has since been deleted, the staff client will show this:

THROWN:
{"payload":[],"debug":"osrfMethodException : *** Call to [open-ils.circ.hold.details.retrieve.authoritative] failed for session [1428431484.040771.142843148433961], thread trace [1]:\nCan't call method \"id\" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/Application/Circ/Holds.pm line 3406.\n\n","status":500}
STATUS:

Kathy Lussier (klussier) on 2015-05-28
tags: added: metarecords
Kathy Lussier (klussier) on 2016-07-07
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Kathy Lussier (klussier) wrote :

Confirmed. I'm not quite sure how you delete a metarecord outside of the database, but, in my case, I deleted all of the records that belong to a metarecord group. The metarecord is still listed in metabib.metarecord, but the master_record field is null.

Rogan Hamby (rogan-hamby) wrote :

I was thinking about this because I ran into this issue with a test system where some experiments were being done by a customer with changing how metarecords are built so existing ones had to be wiped and that affected holds. The approach I used was to map to newly built metarecords with identical or similar values and formats. We could build in a trigger to do that but it seems the scope of use would be awfully narrow, so is it worth it? My instinct is to say that this would be better as a SQL script on the WIKI than worrying about it on the software level until a situation occurs that causes metarecords to have a greater level of churn.

Hello, we ran into this issue recently, but it was limited to only two holds total in our system that would trigger the error when viewing the canceled holds. I used the following query to find instances of these canceled holds that point at non-existant meta records.

select * from
action.hold_request ahr
where
not exists (select 1 from metabib.metarecord mm where mm.id=ahr.target)
and ahr.hold_type='M'
and ahr.cancel_time is not null
;

To fix them I converted them to title holds by changing the type and target.

Josh

Terran McCanna (tmccanna) wrote :

Comment from another ticket from Sitka:

EG 3.1.7

A metarecord is deleted when the last bib is deleted. But the metarecord hold is left behind, which targets a non-existed record now. This, in turn, causes a display issue on Holds screen in the patron record. No hold is displayed.

The metarecord hold needs to, at least, be cancelled. But cancellation of the hold will cause a display issue on the Cancelled Holds tab.

Terran McCanna (tmccanna) wrote :

Still an issue in 3.2.3

Also an issue when the holds expire. In PINES we expire uncaptured holds after 6 months. With title-level holds, the expiration process closes out the title level holds properly, but with metarecord holds it doesn't close out the metarecord hold correctly and causes errors when trying to view the patron's holds in both the staff client and the OPAC.

To clear this, we had to identify and delete the metarecord hold directly from the database.

Michele Morgan (mmorgan) wrote :

We're on 3.2.4, using the web client and just came across this issue.

A patron could not see their holds list at all while logged into the opac.

The patron's hold list also did not load at all in the web client. The count of the patron's holds was accurate, but no rows displayed in the grid.

The cause was traced to a still active M type hold, but the target metarecord for the hold did not exist in metabib.metarecord.

This stranded M hold resulted from the last item on the last bib record linked to the metarecord being deleted. This caused the bib record to be deleted, as well as the metarecord.

The display issue is a bigger problem in the web client than it was in the xul client, since none of the patrons holds are displayed because of the one broken M hold. In the xul client, the intact holds still displayed.

Running Josh's query in comment #3 shows 13 broken M holds in our production system.

As mentioned previously, the holds can be identified and cancelled, but the cancelled hold list will then break. Perhaps metabib.metarecord should have a deleted flag so the hold does not break when the metarecord is deleted.

tags: added: holds
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers