2.5 serials receiving error

Bug #1233340 reported by Ben Shum on 2013-09-30
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen master as of 2013-09-07

When trying to receive serial issuances, we've seen the staff client spit back the following error:

cmd_receive_items failed!

"stacktrace":"/usr/local/share/perl/5.14.2/OpenILS/Application/Serial.pm:1912 /usr/local/share/perl/5.14.2/OpenILS/Application/Serial.pm:1533 /usr/local/share/perl/5.14.2/OpenILS/Application/Serial.pm:1415",
"desc":"Invalid parameters were encountered in a method",
"servertime":"Mon Sep 23 09:49:44 2013",
"note":"get_combined_holdings(): Can't call method \"increment\" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/Utils/MFHD.pm line 576. ; using sdist ID #3814 and 39 issuances,
of which one has ID #394148"

Looking at the warning logs, we also saw (lots of the first one about the no corresponding subfield a):

open-ils.serial.receive_items.one_unit_per: Subfield 'a' has no corresponding caption, ignoring at /usr/local/share/perl/5.14.2/OpenILS/Utils/MFHD.pm line 539
open-ils.serial.receive_items.one_unit_per: Holding is open-ended, cannot convert to last member /usr/local/share/perl/5.14.2/OpenILS/Utils/MFHD.pm line 549
open-ils.serial.receive_items.one_unit_per: Use of undefined value in holding comparison operation at /usr/local/share/perl/5.14.2/OpenILS/Utils/MFHD.pm line 566

the holding_code for issuance is like:


But then the caption/pattern code is like:


So I think the complaining "a" is because the holding_code has it, while the caption/pattern code does not.

My curiosity is whether changes introduced with http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=83f8420b2cac88b11ea6304f7f26952e56bffe80 and related commits caused this behavior to change and make it less willing to accept generated holdings now.

Ben Shum (bshum) wrote :

I believe we also attempted to edit out the holding_code's extra "a" and that didn't help anything either.

tags: added: serials
Changed in evergreen:
milestone: none → 2.5.0-rc
importance: Undecided → Medium
status: New → Triaged
Dan Wells (dbw2) on 2013-09-30
Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Dan Wells (dbw2) wrote :

Possible fix available here:



tags: added: pullrequest
Ben Shum (bshum) wrote :

Tested this and we are now able to receive issues again.

Pushed to master, thanks dbwells!

Changed in evergreen:
status: Triaged → Fix Committed
Dan Wells (dbw2) on 2013-10-07
Changed in evergreen:
assignee: Dan Wells (dbw2) → nobody
Dan Wells (dbw2) on 2013-11-11
Changed in evergreen:
status: Fix Committed → Fix Released

Ben, I'm not sure whether you left merging to rel_2_4 and rel_2_3 for others intentionally or not, or if the bug wasn't targeted at those series until after you merged, but in any case it does fix problems receiving some serials in those release series as well as in 2.5 and master. I've had good results testing 2.4.3 + this patch with patterns that have subfields $i and $j but not $a and b with holdings that have all four (which is wrong, but doubtless caused by predictions back from when the serials code was buggier than it is now).

So I signed off and backported to rel_2_4 and rel_2_3. Thanks!

Also, unless the 2.4 and 2.3 RM's rebuild their release candidates for .4 and .12 respectively, and I don't think that's necessary here, this feature won't appear in releases in those series until .5 and .13 (? if ever), even though the milestones say otherwise.

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

Other bug subscribers