Holds history breaks when old holds connect to a deleted target

[Blake GH]

/usr/sbin/apache2 [ERR :55401:EX.pm:66:147931340355401261] Exception: OpenSRF::EX::ERROR 2016-11-16T11:21:07 OpenSRF::AppRequest /usr/local/share/perl/5.18.2/OpenSRF/AppSession.pm:1086 System ERROR: Exception: OpenSRF::DomainObject::oilsMethodException OpenSRF::AppRequest /usr/local/share/perl/5.18.2/OpenSRF/AppSession.pm:1086 <500> *** Call to [open-ils.circ.hold.details.retrieve] failed for session [1479316864.1130340167.7766207604], thread trace [1]:
Can't call method "id" on an undefined value at /usr/local/share/perl/5.18.2/OpenILS/Application/Circ/Holds.pm line 3412.

Here is the sql that identifies this situation:

select * from action.hold_request where usr in(
select id from actor.usr where usrname='TESTPATRON'
)
-- and hold_type='M' and target not in(select id from metabib.metarecord)
-- and hold_type='P' and target not in(select id from biblio.monograph_part)
-- and hold_type='C' and target not in(select id from asset.copy where not deleted)
and hold_type='T' and target not in(select id from biblio.record_entry where not deleted)
order by hold_type

Uncomment the hold type lines one at a time until you find the type that returns row(s)

[Jason Stephenson (jstephenson)]

I'm seeing this on 2.12.8, and I'm fairly confident it continues to be an issue in later releases.

[Jessica Woolford (jwoolford)]

Just had a report of this in 3.1.16.

[Michele Morgan (mmorgan)]

Master ca 3.9

This is no longer an issue for holds of type T, C, and P. But M type holds are still problematic. I'm marking this as a duplicate of bug 1441301.