Check in takes ~4 sec when item has request on it
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
Attachments
is blocked by
is cloned by
relates to
Checklist
hideTestRail: Results
Activity

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.
Details
Details
Assignee

Reporter

Steps to repro:
Log into Chalmers environment OR Bugfest https://bugfest.folio.ebsco.com/ (ping me if you need login details)
Find an item in inventory
Check it into the check in app
Takes 2 seconds
Now add a request to that item
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 ------------------------------------------------------------------
See this recording: https://drive.google.com/file/d/1wU_63Uv55z9MBIb10bMhk0n20pNPygXh/view relevant sections:
1:09
2:09
Or this recording: https://drive.google.com/file/d/1Sbq4ZbOH50kh16wvwwSsKARsR5EOaRHk/view?usp=sharing
2:18
I tested this later (just a few minutes ago), as Mark Veksler thought it might have been a temp issue related to an OKAPI restart, but the issue still repros. See this recording: https://drive.google.com/file/d/1KGnyoZ7CoDsauwgUt0QAn4Z6rBiDMiuK/view?usp=sharing
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.