Evergreen

Internal Server Error After Placing a Hold

Bug #1918470 reported by Jason Stephenson
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Committed
High
Unassigned
3.5
Fix Committed
High
Unassigned
3.6
Fix Committed
High
Unassigned

Bug Description

Evergreen Version 3.5.3 and master
OpenSRF versions: 3.2.1 and master
PostgreSQL version: 9.6 and 10

While testing bug 1207533 on master today, I noted a consistently reproducible internal server error when hitting "Continue" after placing a hold or hitting "Cancel" while placing a hold.

I have reproduced this behavior on a training server running Evergreen 3.5.3.

The error occurs in both the patron OPAC and in the web staff client.

The error message in the log suggested that the patch for bug 1914116 may have been to blame:

Mar 10 13:52:19 training root: [Wed Mar 10 13:52:19.001431 2021] [perl:warn] [pid 28901] [client 192.168.100.101:36754] egweb: template error: undef error - at /openils/var/templates/opac/parts/header.tt2 line 1.\n, referer: https://training.cwmars.org/eg/opac/place_hold?locg=119&detail_record_view=0&query=coelho&hold_source_page=%2Feg%2Fopac%2Fresults%3Fquery%3Dcoelho%26amp%3Bqtype%3Dkeyword%26amp%3Blocg%3D119%26amp%3Bdetail_record_view%3D0%26amp%3Bsort%3Dpoprel&hold_type=T&hold_target=385397

Reverting the commit for that bug cleared up the internal server errors.

Discussion with Jason Boyer in IRC came to the conclusion that this is likely because the URLs are being filtered twice when holds are placed, thus entities are being re-encoded with percent encoding: http://irc.evergreen-ils.org/evergreen/2021-03-10#i_477445

See original description
Tags: opac holds
Jason Stephenson (jstephenson)
description: updated
Revision history for this message
Jason Stephenson (jstephenson) wrote :

A tip for reproducing this behavior: It appears to only happen after a search whether you place the hold from the search results or from an individual records detail page. A single hit search also seems to lead to an internal server error.

If I click on a record from a carousel link and place the hold that way, it does not cause the internal server error.

Revision history for this message
Terran McCanna (tmccanna) wrote :

We saw this issue begin in 3.6.1 after applying that fix as well. See also, bug 1917513

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
tags: added: holds opac
Revision history for this message
Michele Morgan (mmorgan) wrote :

Adding a note that I can reproduce the Internal Server Error reliably on 3.6.2.

It does not happen on 3.6.1

Jason Boyer noted on IRC that this issue is a result of bug 1914116

Taking the liberty of posting the WIP branch he shared in IRC:

working/collab/jboyer/lp1918470_mkurl_fix

Setting Importance to High since patrons will see this numerous times.

Changed in evergreen:
importance: Medium → High
Jason Stephenson (jstephenson)
Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
Revision history for this message
Jason Stephenson (jstephenson) wrote :

With Jason's patch applied, I get an internal server error when I click Submit to place the hold:

Mar 12 09:46:06 jasontest root: [Fri Mar 12 09:46:06.296721 2021] [perl:error] [pid 18304] [client 192.168.100.100:50356] egweb: Context Loader error: Can't use an undefined value as a subroutine reference at /usr/local/share/perl/5.26.1/OpenILS/WWW/EGCatLoader/Account.pm line 1665.\n, referer: https://jasontest.cwmars.org/eg/opac/place_hold?locg=1&detail_record_view=0&hold_target=3837995&hold_type=T&query=coelho%20the%20spy&hold_source_page=%2Feg%2Fopac%2Fresults/eg/opac/place_hold?locg=1&detail_record_view=0&hold_target=3837995&hold_type=T&query=coelho%20the%20spy&hold_source_page=%2Feg%2Fopac%2Fresults
Mar 12 09:46:06 jasontest root: 192.168.100.100 - - [12/Mar/2021:09:46:05 -0500] "POST /eg/opac/place_hold?locg=1&detail_record_view=0&hold_target=3837995&hold_type=T&query=coelho%20the%20spy&hold_source_page=%2Feg%2Fopac%2Fresults/eg/opac/place_hold?locg=1&detail_record_view=0&hold_target=3837995&hold_type=T&query=coelho%20the%20spy&hold_source_page=%2Feg%2Fopac%2Fresults HTTP/1.0" 500 618 "https://jasontest.cwmars.org/eg/opac/place_hold?locg=1&detail_record_view=0&hold_target=3837995&hold_type=T&query=coelho%20the%20spy&hold_source_page=%2Feg%2Fopac%2Fresults/eg/opac/place_hold?locg=1&detail_record_view=0&hold_target=3837995&hold_type=T&query=coelho%20the%20spy&hold_source_page=%2Feg%2Fopac%2Fresults" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36"

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
Revision history for this message
Jason Stephenson (jstephenson) wrote :

I also get an internal server error when clicking on a title in the result list to see the details page:

Mar 12 09:57:09 jasontest root: [Fri Mar 12 09:57:09.238756 2021] [perl:error] [
pid 18469] [client 192.168.100.100:50698] egweb: Context Loader error: Can't use
 string ("coelho the alchemist") as an ARRAY ref while "strict refs" in use at /
usr/local/share/perl/5.26.1/OpenILS/WWW/EGCatLoader/Search.pm line 87.\n, refere
r: https://jasontest.cwmars.org/eg/opac/results?query=coelho+the+alchemist&qtype
=keyword&fi%3Asearch_format=&locg=1&detail_record_view=0&_adv=1&page=0&sort=popr
el
Mar 12 09:57:09 jasontest root: 192.168.100.100 - - [12/Mar/2021:09:57:08 -0500]
 "GET /eg/opac/record/737341?locg=1&detail_record_view=0&page=0&sort=poprel&badg
es=1&query=coelho%20the%20alchemist/eg/opac/record/737341?locg=1&detail_record_v
iew=0&page=0&sort=poprel&badges=1&query=coelho%20the%20alchemist HTTP/1.0" 500 6
18 "https://jasontest.cwmars.org/eg/opac/results?query=coelho+the+alchemist&qtyp
e=keyword&fi%3Asearch_format=&locg=1&detail_record_view=0&_adv=1&page=0&sort=pop
rel" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chr
ome/89.0.4389.82 Safari/537.36"

Revision history for this message
Jessica Woolford (jwoolford) wrote :

We were seeing this on a server upgraded to 3.5.3. We also got an Internal Server Error when clicking "Back to results" from the record detail page. Reverting commit from bug 1914116 fixes this issue as well.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

The code from bug 1914116, which caused this breakage, has been reverted from the mainline Evergreen repositories.

A new approach will need to be take to resolve that bug.

Changed in evergreen:
status: Confirmed → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.