Internal Server Error After Placing a Hold
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.
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://
description: | updated |
Changed in evergreen: | |
assignee: | nobody → Jason Stephenson (jstephenson) |
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.