[SUP-74] Regression: Inventory Storage Batch Sync APIs upsert functionality returns 409s Created: 08/Jun/22  Updated: 08/Jun/22  Resolved: 08/Jun/22

Status: Closed
Project: Support
Components: None
Affects versions: None
Fix versions: None

Type: Bug Priority: TBD
Reporter: Theodor Tolstoy (One-Group.se) Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Duplicate
duplicates MODINVSTOR-910 Optimistic locking makes Inventory-Ba... Closed
Sprint:
Development Team: None
Potential Workaround: - Fetching the correct version from the APIs? This would slow down the process significantly
- Making the migration tooling maintain a record of what the version is?
Affected Institution:
!!!ALL!!!
RCA Group: TBD

 Description   

Overview:

The Inventory Storage Batch Sync APIs upsert functionality is used extensively at initial data migration from legacy systems and is an important lifeline for fixing wide mistakes or corrections that needs to happen to records on a larger scale (millions of records)

With the introduction of the optimistic  locking functionality in Inventory, the upsert functionality of the batch APIs is no longer functioning without supplying the correct _version property of the individual objects.

Since these APIs - to my knowledge - are mainly used at migration time (migration from the legacy system) in order to overlay data and correct large batches of data, this new constraint makes the upsert part of these APIs more or less useless. 

My proposal is that a new parameter is added, "ignoreOptimisticLocking" or similar, that allows you to sidestep the optimistic locking when using these APIs.

Steps to Reproduce:

  1. Post a batch of instances (with no _version property) to FOLIO using /instance-storage/batch/synchronous
  2. Alter something in the records.
  3. Post the same batch (still, with no _version property)  with some updated records to /instance-storage/batch/synchronous?upsert=true

Expected Results:

The records are received by FOLIO and successfully updated

Actual Results:

The batches fail with a HTTP 409

Additional Information:
JSON schemas do not require the _version property.

Interested parties:



 Comments   
Comment by Theodor Tolstoy (One-Group.se) [ 08/Jun/22 ]

Dupe of https://folio-org.atlassian.net/browse/MODINVSTOR-910

Comment by Kyle Banerjee [ 08/Jun/22 ]

Fetching the correct version via API is not a viable workaround – particularly for large organizations and consortia where the number of records is well into the millions.

Aside from the excessive time and operational impact on library operations, this can't help but impact performance for all users of shared systems.

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