Deleting Metarecords breaks hold interfaces

[Blake GH]

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)]

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)]

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.

[Josh Stompro (u-launchpad-stompro-org)]

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)]

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)]

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)]

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.

[Josh Stompro (u-launchpad-stompro-org)]

EG 3.3

We have been finding holds that match the query in 3 and automatically deleting them... but we had the issue come up again and I had to change my query a bit.

The query in 3 looks for meta holds where there is no metabib.metarecord.

Now we are seeing instances where the metabib.metarecord record exists, but the master_record field is null, which also seems to break the holds display. This also seems like it can come up in non-canceled holds now. I've seen examples of both canceled and non-canceled meta holds that get into this state.

The web client patron holds display breaks with a console error of
error calling method open-ils.circ.hold.details.batch.retrieve.authoritative : 500 : *** Call to [open-ils.circ.hold.details.batch.retrieve.authoritative] failed for session [-], thread trace [0]:
Can't call method "id" on an undefined value at /usr/local/share/perl/5.20.2/OpenILS/Application/Circ/Holds.pm line 3466.

I've see instances where this keeps any holds from being shown, and situations where some holds will display, but any valid holds after the bad meta hold won't get displayed... so those may be harder to detect.

This query seems to spot this new situation.

select ahr.id,ahr.request_time, ahr.cancel_time, ahr.target, ahr.usr,mm.*
,mmsm.*, bre.deleted
from action.hold_request ahr
JOIN metabib.metarecord mm ON mm.id=ahr.target
JOIN metabib.metarecord_source_map mmsm ON mmsm.metarecord=mm.id
JOIN biblio.record_entry bre ON bre.id=mmsm.source
WHERE
ahr.hold_type='M'
AND mm.master_record IS NULL
AND ahr.fulfillment_time IS null
;

Josh

[Michele Morgan (mmorgan)]

Still an issue in master ca 3.9. In the staff client, a broken M hold results in none of the patron's holds displaying on the patron holds screen. For a patron logged into the opac (tpac or bootstrap), attempting to view holds produces an internal server error.

Note that the similar issue with P type holds was fixed in bug 937789.

[Jessica Woolford (jwoolford)]

Still and issue in version 3.11