NYPL-Simplified/circulation

Incorrect holds total reported in loans feed

winniequinn opened this issue · 1 comments

If a user places a hold on a book and then requests their loans feed, they'll receive something that looks like the following:

...
<link ...>
  ...
  <opds:holds position="1" total="0"/>
  <opds:copies available="0" total="2"/>
  ...
</link>
...

Note that opds:holds["position"] == 1 but opds:holds["total"] == 0. This violates the reasonable assumption that opds:holds["position"] <= opds:holds["total"]. After speaking with @courte, this is believed to be a bug.

If possible, it would be great if we could get this fixed. The client in a soon-to-be-current version will try to enforce the above invariant and will become upset when it does not hold.

The two pieces of information can be inconsistent because they come from different sources. The hold position is associated with the hold, and for a given distributor, it's obtained through an API call called something like getHolds. Here's an example of a document returned by such an API call.

This document generally doesn't mention the total number of holds, so we have to get that from a different API call. Depending on the distributor, this call might give information about the current state of the license. Or it might give information about events that happened to the license in the past, allowing us to build up a more-or-less accurate picture of the current state.

Immediately after you've put a hold on a book, your hold information is current, but the license information is out of date.

I can't update the license information based on information I get from the hold, because we might later get a 'item was put on hold' event corresponding to your hold, which would make it look like there are more holds than there really are. But I can change the code that generates the OPDS so that it uses your hold position as the total number of holds if the total number of holds is clearly out of date.

I don't know what it means in this context for the client to become upset, but we don't control all the OPDS servers and I would expect a client to be able to handle this situation with degraded functionality.