Comment 1 for bug 1721133

Adding a link to a discussion on IRC:

http://irc.evergreen-ils.org/evergreen/2017-10-03#i_328019

Also a database query to identify items that are possible victims of this bug. It uses the auditor.asset_copy_history to find currently uncataloged items that previously had a call number.

select distinct on (cp.id) cp.id as copy_id, cp.deleted as copy_deleted, cp.barcode, hist.call_number as previous_call_number, cp.call_number as current_call_number, cn.record as previous_bib, cn.label as previous_cn_label, cp.edit_date as copy_edit_date from asset.copy cp
join auditor.asset_copy_history hist on cp.id = hist.id
join asset.call_number cn on hist.call_number = cn.id
where cp.call_number < 0
and hist.call_number > 0
order by 1,8

Thanks to Jason Stephenson for refinements to the query.

Also attaching log entries showing the new asset.call_number row being created with id 17932410, but asset.copy is updated with call_number -1 after retrieval of the new call_number id fails.

These entries were found in the gateway log:

2017-09-26 15:40:53 brick3 osrf_json_gw: [INFO:167886:osrf_app_session.c:1177:15064548421678862] [open-ils.search] sent 248 bytes of data to router@brick3/open-ils.search
2017-09-26 15:40:53 brick3 osrf_json_gw: [INFO:167886:./osrf_json_gateway.c:328:15064548421678862] [192.168.0.19] [5e4a0d99525949094d7e355ac74e9d0f] [en-US] open-ils.search open-ils.search.callnumber.fleshed.retrieve.authoritative 17932410
2017-09-26 15:41:53 brick3 osrf_json_gw: [INFO:167886:osrf_app_session.c:394:15064548421678862] Returning NULL from app_request_recv after timeout: open-ils.search.callnumber.fleshed.retrieve.authoritative [17932410]
2017-09-26 15:41:53 brick3 osrf_json_gw: [INFO:167886:./osrf_json_gateway.c:435:15064548421678862] Completed processing service=open-ils.search, method=open-ils.search.callnumber.fleshed.retrieve.authoritative