Epic to link all support issues located in Dev projects (SUP-12)

[ERM-1915] Exception editing an Agreement having Agreement line with large number of poLines Created: 06/Oct/21  Updated: 06/Dec/23  Resolved: 10/Nov/21

Status: Closed
Project: ERM Platform
Components: ui-agreements
Affects versions: None
Fix versions: None
Parent: Epic to link all support issues located in Dev projects

Type: Bug Priority: P1
Reporter: Carole Godfrey Assignee: Aditya matukumalli
Resolution: Done Votes: 0
Labels: agreements, erm, support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Screen Shot 2021-10-06 at 4.33.06 PM.png     PNG File image-2021-11-01-14-03-26-986.png     Text File okapi-url-order-lookup.txt    
Issue links:
Defines
defines ERM-1919 ui-agreements release. Fix version: 8... Closed
Sprint: ERM Sprint 126, ERM Sprint 127
Development Team: Bienenvolk
Release: R3 2021 Bug Fix
Affected Institution:
MI State University/Library of Michigan
Epic Link: Epic to link all support issues located in Dev projects

 Description   

Overview:

Attempting to edit an Agreement that has an Agreement Line (which has 180 poLines) results in an error message (per attached image)

Network traffic shows request to 
https://okapi-url/orders/order-lines (file attached) that is excessive in length (9420 characters) and has an HTTP status code of 414

This is observed on an Iris HF3 environment
Steps to Reproduce:

  1. Log into some FOLIO environment 
  2. Create. an agreement with a single agreement line (with 180 poLines)
  3. Attempt to edit agreement

*Expected Results:*Agreement can be edited (without exception dialog box)

Actual Results: 

Exception dialog box - Observe. ERROR: in module @folio/agreements, operation GET on resource 'OrderLines" failed, saying: Failed to fetch 
Additional Information:
Aditya matukumalli I suspect we need to implement logic that means we do multiple requests for long lists of order lines from the Agreement UI (see comment from Zak below re similar issue in ui-users

URL:
Interested parties: Molly Driscoll



 Comments   
Comment by Owen Stephens [ 07/Oct/21 ]

Before we dive in and look at a technical fix, I'd be interested in understanding the scenario which leads to a single agreement line being linked to such a large number of order lines - while we've not limited the number of POLs that can be added to a single agreement line, having such large numbers seems sub-optimal and while one option for us to "fix" might be to do multiple requests to the OrderLines API, I'd like to understand the context and if there are other approaches we might take to supporting this scenario.

Comment by Anya [ 11/Oct/21 ]

Molly Driscoll Please see Owen Stephens's comment... 

Comment by Anya [ 11/Oct/21 ]

Support - Owen Stephens what   project should this ticket be in rather than SUP.

Comment by Anya [ 11/Oct/21 ]

Owen Stephens the priority is not set but the release is set for this hf3 – Support is not sure that it warrants a P1 or a HF3 candidate ... please weigh in on this. 

Comment by Owen Stephens [ 11/Oct/21 ]

Anya I didn't set the release, but I don't think this is a P1 / H3 candidate

Comment by Owen Stephens [ 11/Oct/21 ]

Anya from my perspective I'd like to get the issue bottomed out before we move it into a different project - but if this is a problem from a support workflow it could go into the ERM Platform project - but I'd really prefer to have actionable stories in there which this isn't (yet)

Comment by Molly Driscoll [ 13/Oct/21 ]

Owen Stephens I've been working with this library and here is a little background on their setup. They have decided to create agreements with agreement lines for the package, rather than individual titles. This makes it easier to manage new title acquisition because they're selecting in a single place (the eHoldings app) and their controlling license terms are automatically cascading to the selected titles without having to take the additional step of adding a new agreement line for each title. However, they are paying for the selections in a few e-book packages on a title-by-title basis, so need to attach the POL for each title to the agreement line to establish the connection to the acquisitions module. For some of their e-book packages, this represents a larger quantity of POL. This issue doesn't apply as much to their journal agreements, where they are typically paying at the package level, rather than the title level. I hope this helps to clarify, but please let me know if you need additional info. Thanks!

Comment by Anya [ 18/Oct/21 ]

Support : Zak Burke will be looking into this... 

Comment by Zak Burke [ 18/Oct/21 ]

Owen Stephens, on a technical level, this sounds exactly like UIU-1264 Closed . We resolved that in ui-users with a function that breaks the long list of query parameters into chunks and runs the queries in series. It's not beautiful, but it gets the job done. Perhaps that approach could be leveraged here? Dunno; it just felt similar.

Comment by Anya [ 25/Oct/21 ]

Support: Owen Stephens just checking to see if you saw the comment above... 

Comment by Anya [ 01/Nov/21 ]

Support: Owen Stephens please see comments above

 

Cc Molly Driscoll

Comment by Molly Driscoll [ 01/Nov/21 ]

Owen Stephens the library reports this persists in their Juniper dry-run environment. Do we have a timeline for resolution? At this time they need to acknowledge the error several times to even access the agreement record, then the record itself provides no access point to the order.

 

Comment by Owen Stephens [ 02/Nov/21 ]

Thanks Anya Molly Driscoll Zak Burke. I've asked Adi prioritise this so we can fix this issue for the Kiwi release.

Comment by Owen Stephens [ 03/Nov/21 ]

Discussion at ERM delivery call 3rd November:
Limit on URL length = 4096 (need to confirm this)
If we step with 80 POLs per request we should be under this
We need to decide how many simultaneous requests we should support - suggested that 5 might be the right number

OS to setup test case on kiwi bugfest

Generated at Thu Feb 08 22:22:06 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.