Item in transit for hold doesn't check if still needed for hold if checked in at location other than pickup library

[Benjamin Murphy]

3.11.1

We've discovered behavior that when checking in material that's in transit, Evergreen just sees its in transit and redirects rather than checking to see if it is still needed.

1. an item is needed for hold, captured and put in transit at library A

2. patron cancels hold

3. arrives at library (B) other than destination library, is checked in

4. rather than check if its needed for hold and where it should be going, its simply sees its in transit and redirects to destination library (C)

5. destination library (C) receives item, checks it in and realizes the hold was canceled before it even arrived at (B)

Also, when this scenario occurs, there's no record of it in the action.transit_copy table. Its "checkin" at library B is not recorded

[Galen Charlton (gmc)]

In this scenario, is library B acting as a sort of transit hub that is responsible for forwarding on items bound for library C? Or a main library sorting through a set of received books to pass them on to the branches?

[Benjamin Murphy (benjamin.murphy)]

In the precise scenario we encountered and then tested, library A should have sent the book to library C. Library B had a similar name but shouldn't have been involved at all. They however received the book, checked it in to get a transit slip, and instead of this book being transited back home because the hold had been cancelled after it was sent from A, the transit slip said to send it on to what had been the original destination (library C), where it was then sent, checked in, and it was discovered the hold had been cancelled. When checked in at Library C, the book was then routed back to library A.

[Dan Guarracino (dguarracino)]

We've also encountered this recently on 3.11.3. If an item is in transit for a hold and ends up being checked in at a library other than its destination, Evergreen only considers the fact that the item should still be in transit to its destination and doesn't bother to check whether it is still needed to fulfill the hold at its end destination.

We ended up with a very weird variation of this that interacted with another bug described in 2058786.