Check in takes ~4 sec when item has request on it

Description

Steps to repro:

  1. Log into Chalmers environment OR Bugfest https://bugfest.folio.ebsco.com/ (ping me if you need login details)

  2. Find an item in inventory

  3. Check it into the check in app

  4. Takes 2 seconds

  5. Now add a request to that item

  6. Check it in again

Expected: Check in should take less than one second after any notes have been presented regardless of whether there are requests or not

Actual: Takes 4 seconds when there is a request on the checked in item. I added another request and the performance was still 4 seconds.

Additional info:

  • While checking in an item that hasn't been requested is taking twice as long as it should (2 seconds instead of one) the focus of this issue should be the 4 seconds it takes when the checked in item is requested. We need to address this first.

  • In some cases, some popups will display on the check in screen before the item has actually been checked in For example, if the item is a multipiece item or if there are check in notes. These popups are displaying really quickly and don't seem to be an issue. Also, they don't seem to be contributing much to the overall latency when checking in a requested item. If you measure the time passed after these popups are closed before the item is actually checked in, it still takes 4 seconds.

  • 2019-09-19 Screencast showing bug in Bugfest environment: https://www.screencast.com/t/1zhK5C0b2oES

OLD RECORDINGS ------------------------------------------------------------------

Additional info: The last recording shows that there are also performance issues saving a changed item record and saving a new request. I will create separate bugs for those.

NOTE: I tested this on computer and it wasn't as slow, but it seems like it might get slower the more you do it.

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Attachments

2

Checklist

hide

TestRail: Results

Activity

Show:

Cate Boerema October 15, 2019 at 2:57 PM

Just talked to Mark V. He votes to not hotfix this one to 3.1 since 3.2 upgrade is next Tuesday

Hongwei Ji October 15, 2019 at 1:52 PM

they are included in Q3.2. The risk is low if we want to deploy to Chalmers now. Since FSE is actively working on Chalmers migration to 3.2, I will defer you and MarkV to decide.

Cate Boerema October 15, 2019 at 1:42 PM

Thanks , have they been included in the Q3.2 release so that when Chalmers upgrades on the 22nd, they will get these fixes?

Do you think we should hotfix them to Q3.1 between now and then? I think they can probably wait until next week, but if it's easy and low risk to deploy before then, we might just do it.

Hongwei Ji October 15, 2019 at 12:47 PM

, those releases have not been deployed to Chalmers. I am not aware deployment requests for these releases.

Cate Boerema October 15, 2019 at 10:07 AM

correct. I haven't been able to repro this in BF3.1, BF3.2 or snapshot for quite a while. I think we can close this.

I have created a CHAL issue for this () so it will appear on the Chalmers board: https://folio-org.atlassian.net/secure/RapidBoard.jspa?rapidView=132&selectedIssue=CHAL-37

do you know if the performance hotfix releases related to this issue have already been deployed to Chalmers or will they only become available to Chalmers when they upgrade to 3.2? This will determine which column belongs in for now.

Done

Details

Assignee

Reporter

Priority

Development Team

Core: Platform

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created August 27, 2019 at 2:32 PM
Updated October 15, 2019 at 2:57 PM
Resolved October 15, 2019 at 10:07 AM
TestRail: Cases
TestRail: Runs