Uploaded image for project: 'mod-inventory-storage'
  1. mod-inventory-storage
  2. MODINVSTOR-677

POST /inventory-hierarchy/items-and-holdings Not Handling Errors Gracefully

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: P2
    • Resolution: Done
    • Affects Version/s: 19.4.4
    • Fix Version/s: 21.0.0
    • Labels:
      None
    • Template:
      Standard Bug Write-Up Format
    • Sprint:
      Prokopovych - Sprint 113, Prokopovych - Sprint 114, Prokopovych - Sprint 115, Prokopovych - Sprint 116
    • Story Points:
      5
    • Development Team:
      Prokopovych
    • Release:
      R2 2021

      Description

      Overview:

      When there is a data issue that causes the database layer (in this case the view get_items_and_holdings_view) to return an error, it seems like the API /inventory-hierarchy/items-and-holdings does not handle the error gracefully. It returns a HTTP 500 error but at the same time the database connection gets forcefully aborted. (The DB's connection state turned into "idle in transaction (aborted)".)  Consequently, if more of these errors happened, more DB connections would get killed until there are no more DB connections left in the connection pool. mod-inventory-storage does not know that it has run out of DB connections and it does not replace the DB connections when they are being aborted. 

      Steps to Reproduce:

      1. Set up the database to have an instance which has an associated item that has a non-UUID statisticalCodeId, in the field item.statisticalCodeIds
      2. Make this API call https://<okapi-url>/inventory-hierarchy/items-and-holdings with the instance ID in step 1, such as:  {"instanceIds":["07e95d3d-7c42-4993-9dc9-db1aed308d3e"],"skipSuppressedFromDiscoveryRecords":true}
      3. a HTTP 500 code will return.  Notice in pgAdmin's dashboard there is a connection showing "idle in transaction (aborted)".
      4. Repeat steps 1-3 for the DB_MAXPOOLSIZE times and FOLIO will be unusable. 

      Expected Results:

      • The code handles the error more gracefully so that DB connections don't get aborted
      • DB connections don't get aborted.
      • If connections are aborted, they should be replaced with new ones automatically

      Actual Results:

      • DB connections get aborted
      • FOLIO applications that call inventory APIs hang and errored out, can't access the database.

      Additional Information:
      Some thoughts: Perhaps view need to handle the error more gracefully to relay to the caller that there is an error so that the caller could handle the error more gracefully as well. 

      Interested parties:

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                felkerk Kyle Felker
                Reporter:
                mtraneis Martin Tran
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases