Skip to:

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

DCB Admin -- multiple versions of the same item in a list

Description

Hi Casey – please take a look at this example of a list of items from Shared Index → items. The screen is rendering in an odd way showing “duplicates” of the same item record number from the same library. Here is a screenshot to illustrate:


Screenshot 2025-02-26 at 12.54.24 PM.png

Attachments

3
  • 27 Feb 2025, 12:18 PM
  • 27 Feb 2025, 11:11 AM
  • 26 Feb 2025, 08:58 PM

Activity

Show:

Marc Johnson February 27, 2025 at 12:29 PM
Edited

If no filters are provided, you get a much smaller response without any duplicates

At least that means this issue may not be affecting use of live availability in Locate or during resolution

It is a little strange that there are duplicates when the mappings have succeeded as well

A next step is probably to get the response from the API in the local system. It could be possible that there are duplicates in that response, otherwise dcb-service is somehow generating them

It appears that at least one of the duplicates is coming from Christian County Library, a Sierra Host LMS


Ok, I think my initial code investigation was wrong and owning context affects multiple the Host LMS types

seems to exclude not just the duplicates, but also some valid items (see 5707268, below).

This could be a mismatch between the information sent back from live availability and the filters that are applied

IIRC, not all of the impact of the filters can be interpreted based upon the fields that are included in the response e.g. deleted, agency is supplying

Casey Henderson February 27, 2025 at 12:18 PM
Edited

Thanks Marc. If no filters are provided, you get a much smaller response without any duplicates (attached). Strangely, this is different to what is returned when the filters parameter is set to “none”, and seems to exclude not just the duplicates, but also some valid items (see 5707268, below).

Loading file...

It appears that at least one of the duplicates is coming from Christian County Library, a Sierra Host LMS:

{ "id": "5707268", "status": { "code": "AVAILABLE" }, "location": { "code": "92f", "name": "Nixa Adult Fiction" }, "barcode": "37921002645814", "callNumber": "ANDREWS, MARY KAY", "isRequestable": true, "isSuppressed": false, "holdCount": 0, "availabilityDate": "2025-02-27T11:02:32.963484075Z", "localItemType": "CC Book", "canonicalItemType": "UNKNOWN - Item has no owning context", "localItemTypeCode": "40" }, { "id": "5707268", "status": { "code": "AVAILABLE" }, "location": { "code": "92f", "name": "Nixa Adult Fiction" }, "barcode": "37921002645814", "callNumber": "ANDREWS, MARY KAY", "isRequestable": true, "isSuppressed": false, "holdCount": 0, "availabilityDate": "2025-02-27T11:02:32.963484075Z", "localItemType": "CC Book", "canonicalItemType": "UNKNOWN - Item has no owning context", "localItemTypeCode": "40" }, { "id": "5707268", "status": { "code": "AVAILABLE" }, "location": { "code": "92f", "name": "Nixa Adult Fiction" }, "barcode": "37921002645814", "callNumber": "ANDREWS, MARY KAY", "hostLmsCode": "CHRISTIAN_COUNTY", "owningContext": "CHRISTIAN_COUNTY", "isRequestable": true, "isSuppressed": false, "holdCount": 0, "availabilityDate": "2025-02-27T11:02:32.963484075Z", "localItemType": "CC Book", "canonicalItemType": "CIRC", "localItemTypeCode": "40", "agency": { "code": "9chrs", "description": "Christian County Library" } },

Marc Johnson February 27, 2025 at 12:14 PM

Addendum: A quick review of the code suggests that owning context might only be set for items from a Polaris Host LMS

Are all of the duplicates coming from a Polaris Host LMS?

Marc Johnson February 27, 2025 at 12:02 PM
Edited

and this is the RTAC response with filters

Are the duplicates still present when no filter parameter is provided?

AFAIK, it is only the shared index view that uses this parameter

I would say something has gone arwy with rtac if the id or barcode is for the copy

As there can be multiple items associated with each bib, I would expect the id and barcode to be for each item / copy rather than the bib

the grid always expects ‘id’ to be unique - this is why you end up seeing even more duplicates in the grid itself

Separate to the behaviour described in this issue, as the id is only unique within the local system (mostly the same as Host LMS), it is not guaranteed that id will be unique in the response from live availability

however, the ‘first’ item has an associated agency and a valid canonical item type, as well as a valid Host LMS code and an owning context

I wasn’t really involved in the owning context work, so I don’t really understand it (Alex is the best person for this)

However, IIRC from previous investigations, I believe it happens after the location to agency mapping and so it’s possible that if that isn’t present, then the owning context will also not be set and that might cause erroneous failures later in the process e.g. other mappings based upon the owning context

I wonder if perhaps there is some ‘retrying’ going on here - maybe it initially creates the items without the owning context, and then it gets it right on the third try, preventing future duplicates?

This could be a possibility. I’m not aware of a flow where that could happen

That said, the owning context should_ only matter after the response from local system has been received, so my initial thoughts are that they are independent. There could be something causing repeats after the response has been received from the local system

Are there examples of the repeats from Host LMS of different types (FOLIO, Polaris etc)?

Has the update to netty caused this side affect ?

I don’t know. My guess would be that this behaviour predates that work. As it is not possibly to deploy to staging without that version of netty or later, the only way to test that hypothesis in staging would be to upgrade micronaut

Chas Woodfield February 27, 2025 at 11:34 AM

I would say something has gone arwy with rtac if the id or barcode is for the copy and not the bib, the end users should not notice it because the agency is not being returned but the status being returned is AVAILABLE.

Has the update to netty caused this side affect ?

Details

Assignee

Reporter

Parent

Priority

Created February 26, 2025 at 8:58 PM
Updated 18 hours ago

Flag notifications