Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Saving edited item record VERY slow after adding request, checking out, viewing loan etc.

Description

NEW REPRO STEPS:

I am finding this is actually quite easy to repro. It doesn't require waiting hours or anything as I initially thought. I just tried this in testing (see screencast here: https://drive.google.com/file/d/1k1Ferv58uJlLZ-AYyw0qHsFtRX_Hbzlq/view?usp=sharing). These are the steps I took:

  1. Go to Inventory

  2. Search ABA

  3. Open an item in ABA

  4. Edit and save - Took 5 seconds for me

  5. Create a request on the item

  6. After request is created, go back to item and edit again - Took 6 seconds

  7. In requests app, use some filters to find the request again and copy the barcode

  8. Check the item out to the requester

  9. From checkout, link over to Loan details record

  10. From loan details, click barcode to get back to item record

  11. Edit the item and save - Took 11 seconds this time (I think)

  12. Search Inventory for Bridget

  13. Open an item in Bridget Jones and edit

  14. Save item - Took 20 seconds this time

----------------------------- OLD STEPS ----------------------------------
Steps to repro:

  1. Log into any environment (repros in Chalmers which is 3.1 but also repros in folio-snapshot)

  2. Go to Inventory and find an item

  3. Edit the item (I added a check in note)

  4. Save the changes

  5. Performance starts out okay at the beginning of the day but over the course of the day, if the tab is left open, it deteriorates. The performance declines for saves in other apps, as well (Requests (https://folio-org.atlassian.net/browse/UIREQ-324#icft=UIREQ-324), Users and maybe more)

Expected: Save should be snappy (not sure the exact SLA)

Actual: Takes around 18 seconds!! See attached screencast

Additional info: A hard refresh (ctrl F5 on windows) or opening in new tab/window improves performance significantly

NOTE:

  • I tested this on computer and it was much faster, but then we did it again and it had slowed down to about 3 seconds. It seems like the performance on this might get worse the more you use it.

  • I also retried test in a fresh browser window on my machine and it was a lot faster

TESTS:

  • Reproduced on folio-snapshot on 's machine at approximately 10:30 am CET on 2019-08-29. Theo opened developer tools and copied some info which might be helpful in the attached txt file.

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Attachments

3
  • 11 Sep 2019, 08:28 PM
  • 29 Aug 2019, 08:41 AM
  • 27 Aug 2019, 03:01 PM

Checklist

hide

TestRail: Results

Activity

Show:

Zak Burke October 16, 2019 at 3:43 PM

... and stripes-connect v5.4.1 was packaged into stripes v2.11.3 and that was merged into the platform q3.2-2019 branches today.

As noted, this issue (and a few others stashed in UI projects) turned out to be issues in stripes-connect or stripes-core. It isn't clear what to do about the fix-version field in tickets like this one. We could make a new release, branched from its Q3.2-2019 tag, so we could have a fix-version here, but I'm not sure there is any value in that.

Ryan Berger October 16, 2019 at 3:36 PM

This ended up being a stripes-connect issue (related to mutate epics getting reregistered whenever returning to previously visited views), so I think we'll need to move it there to get the correct version number. It was corrected and released in stripes-connect 5.4.1.

Jakub Skoczen October 16, 2019 at 2:02 PM

Guys, please fill out the fixVersion and please remember to fill it out before closing tickets. Thanks.

Cate Boerema October 16, 2019 at 1:13 PM

  • First save of item - < 2 seconds

  • Second save (after creating request) - < 2 seconds

  • Third save (after checkout and visit to loan details) - 3 seconds

  • Fourth save (new item record) - 3 seconds

this seems to be working sooo much better now. I think we can call this fixed. Is it already included in the Q3.2 release so Chalmers will get it when they upgrade next week? If not, can we please get a release made? Dropdead deadline for Q3.2 releases is today "mid day" per Mark Veksler.

Thank you so much for all your work on this!!

Ryan Berger September 26, 2019 at 5:03 PM

I have a few theories but nothing concrete yet for the root cause. has created a nightmare test that recreates the issue and shows time slowly increasing with each save. I mention that since once I have a working solution, I can use the nightmare test to scientifically show that the time stops increasing with each save.

Done

Details

Assignee

Reporter

Tester Assignee

Labels

Priority

Sprint

Development Team

Stripes Force

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created August 27, 2019 at 3:01 PM
Updated October 16, 2019 at 3:43 PM
Resolved October 16, 2019 at 1:13 PM
TestRail: Cases
TestRail: Runs

Flag notifications