Details
-
Bug
-
Status: In Code Review (View Workflow)
-
TBD
-
Resolution: Done
-
None
-
None
-
None
Description
Steps to reproduce
(It should be able to reproduce them using only item-storage/items, but this is the actual scenario I had.)
- With /item-storage/items: Using consecutive queries and paging through the results with a limit 1000 and an offset that increments by 1000 for each query, fetch all existing items where (effectiveLocationId=="f4c5afee-261a-43d1-9708-cc123aaba50a")
- With /inventory/items: Using consecutive queries and paging through the results with a limit 100 and an offset that increments by 100 for each query, fetch all existing items where (effectiveLocationId=="f4c5afee-261a-43d1-9708-cc123aaba50a")
Expected result
All items matching the criterium are returned. mod-invetory and mod-inventory-storage return the same number of items.
Actual result
mod-inventory-storage returns 11 351 items, mod-inventory only 11 000. Not only is the latter number too low, but it's suspiciously even. N.B. that these numbers come from counting the actual records returned, not from the totalRecords value. The totalRecords value returned is, in both cases, 11 075.
Investigation
Knowing that mod-inventory-storage returns 11 351 items matching this criterium, let's make this request in Postman:
{{okapi-url}}/item-storage/items?query=(effectiveLocationId=="f4c5afee-261a-43d1-9708-cc123aaba50a")&limit=100&offset=11100
It should return records 11 100-11 200. Alas, instead it returns this:
{ "items": [], "totalRecords": 11075 }
Could this have something to do with the fact that our offset value (11 100) is higher than the estimated totalRecords (11 075).
Let's test that idea by lowering the offset to 11 000, and changing the limit to 400, so that the range encompasses the actual number of records. Lo and behold, this returns 351 items. (totalRecords is still 11075.)
Interpretation
If the offset value is higher than totalRecords, the query request will return 0 items even if there are actually more records.
Implications
In many cases this probably wouldn't be noticeable, but if the limit used (in order to avoid too long query string errors) is less than the difference
actual number of records - totalRecords, how do you get to those last records?
For example this query
{{okapi-url}}/inventory/items?query=(effectiveLocationId=="f4c5afee-261a-43d1-9708-cc123aaba50a")&limit=100
If I set the limit to a higher value the request will return a 500 error.
totalRecords is 11075, but the actual number of records is 11351. (I know the actual number of records because I tried the same query but with a higher limit in item-storage.)
The first 111 requests, with offsets between 0 and 11000 return 100 items each. But then I get to
{{okapi-url}}/inventory/items?query=(effectiveLocationId=="f4c5afee-261a-43d1-9708-cc123aaba50a")&limit=100&offset=11100
which returns an empty items list.
Attachments
Issue Links
- is blocked by
-
MODINVSTOR-559 Release mod-inventory-storage 19.3.2
-
- Closed
-
-
RMB-684 GET query returns no records when offset value > estimated totalRecords
-
- Closed
-
- relates to
-
FOLIO-2557 hitcount estimation is way off
-
- Closed
-
-
MODINVSTOR-321 999 999 999 Records found
-
- Closed
-
-
MODINVSTOR-468 hitcount related issues in Q1
-
- Closed
-
-
UIIN-1049 Paused due to POC of Elastic Search. Bugfest: Inventory. Effective Location Result Counts Don't Add Up (Off by Unacceptable Amount) And Seem Suspicious
-
- Closed
-
-
UIIN-1055 Bugfest: Inventory. Sorting by Title gives different result counts than no sort when *searching*
-
- Closed
-
-
UIIN-1070 Paused due to POC of Elastic Search. BugFest: Inventory. Search for Term and Filter by Status = Available Always Results in 1,000 Results
-
- Closed
-
-
UIIN-1129 SPIKE: JTST Environment. Inventory. Search for Status = Available, Sort by Contributor Gives No Results in Main Pane Despite Result Count of 93,717
-
- Closed
-