Web client: Transit slip printing with wrong information

[Blake GH]

EG 3.0.2

We are seeing this crop up often. Many of our libraries are receiving materials in the courier that were not supposed to go to them. Upon checkin, the items are routed elsewhere. It looks like it has something to do with stale variables during the checkin processing in the web based staff client. We have caught it in the act, where the printed receipt contains the wrong information in the dest library. But if you check it in a second time, it's correct! This sounds very much like an angular timeout/deferred issue.

[Terran McCanna (tmccanna)]

We have not been able to reproduce this on our test server, but we'll keep a close eye on it after the upgrade.

[Terran McCanna (tmccanna)]

We've started to get a few reports of this today since we went live on 3.0.2.

[Terran McCanna (tmccanna)]

Example:

1) Item X had a previous transit from ARCPLS to GCHR-CCO where it was last checked out.
2) It was returned to GCHR-CCO on 1/10/2017, reshelved, and pulled off the shelf to fill a hold request on 1/16/2018.
3) When GCHR-CCO staff scanned it, it printed out a transit slip saying it needed to go to GCHR-CCO (where it already was).
4) When GCHR-CCO noticed that and scanned it again, it printed out the correct MCCLS-HQ transit slip.

[Terran McCanna (tmccanna)]

I'm pushing this to "High" since it's presenting incorrect information to staff which can cause items to be misrouted.

[Terran McCanna (tmccanna)]

Attaching another example of incorrect transit slip printing, then a rescan printing the proper transit slip.

[Anna Goben (agoben)]

I can confirm reports of this in our 3.0.2 instance as well.

[Terran McCanna (tmccanna)]

Blake and Anna - have either of you come up with a solution or workaround other than to ask everyone to scan every check in twice?

[Tina Ji (tji)]

This could be related. So I put it here, instead of a new bug.

On Holds/Transit tab on Scan Item screen, the transit shown up there is the earliest transit record in transit_copy table for the item, even though the item does not have open transit record.

Tina Ji
BC Libraries Coop

[Terran McCanna (tmccanna)]

Tina - there is a fix for that problem in 3.0.3 (https://bugs.launchpad.net/evergreen/+bug/1729922)

[Heather Lindskold (heatherlindskold)]

We have had several mis-routed items due to this bug. Attaching photo of first and second prints-- it's especially problematic when it prints the org unit name of the library the item is at--which staff interpret as needing to be routed to the public holds shelf (even though that is not the verbiage they would normally see for public holds shelf items).

[Bill Erickson (berick)]

Can we say with relative certainty that when it shows bogus transit data, it's data that was previously correct for the copy in question? It's not apparently random data?

To rule out DB replication delay issues, can anyone reporting this issue confirm they run on a single database -- all reads and writes go to the same PG instance? I.e. no database replicas?

[Bill Erickson (berick)]

"I.e. no database replicas?" => "I.e. no database replicas read by the application?"

[Terran McCanna (tmccanna)]

>>Can we say with relative certainty that when it shows bogus transit data, it's data that was previously correct for the copy in question? It's not apparently random data?<<

I believe that's true. The ones we have seen have all printed the current location, which would have been the last place that the item transited to.

[Bill Erickson (berick)]

Thanks, Terran.

Thinking about this a little more, DB replication lag would not explain the application fetching a transit that was completed days in the past (as in comment #3).

The usual transit queries explicitly look for transits whose destination receive time is null. I confirmed the one explicit query in the browser client (circ.js) that fetches transits is filtering on dest_recv_time=null. (Notably it's not filtering on cancel_time, but it sounds like canceled transits are not the issue here).

Apparently there's a query somewhere where the correct filtering is not applied. I tried a few experiments but was unable to reproduce. We really need a way to reliably reproduce the issue using concerto data. With that we could probably track it down pretty quickly.

[Blake GH (bmagic)]

One of our libraries reported that it was repeating the data from a previous transit slip and it only got the right data upon a second check-in.

[John Amundson (jamundson)]

I have been doing some testing on this bug.

The issue seems to occur when the check-in closes one transit and opens another in the same scan. Any scenario where check-in does this can be used to reproduce the bug. Here is one way to reproduce the issue:

1. Sign in as Library A.
2. Check in an item owned by Library B that does not have any holds associated with it. This will send the item in transit to its home, Library B.
3. Place a hold on the item to be picked up at Library C.
4. Sign in as Library B.
5. Check in the item. [Upon check in, the item should be transited to Library C to fill the hold, but instead...] The transit pop-up and printout will show that the item needs to be transited to Library B instead of Library C.

Side note: the transit in the system still appears to be correct - transit to library C - but the pop-up displays the incorrect library name. In fact, the pop-up will show Library B's name but the address will be the address for library C.

[Bill Erickson (berick)]

Branch pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1740537-transit-slip-mismatch

This branch specifically fixes the issue described by John in the previous comment. It /might/ resolve all of the noted issues from the bug. Testing will tell.

The gist of the bug is the browser is assuming that the transit it has available (from the API) is the new hold transit, instead of the just-closed transit. The fix teaches the browser to go get the newest transit each time it needs it for the transit dialog.

[Terran McCanna (tmccanna)]

Yaaaay! Thanks, Bill! Haven't tested yet due to conference... next week...

[Galen Charlton (gmc)]

Tested and signed off. Branch is user/gmcharlt/lp1740537_signoff.

[Mike Rylander (mrylander)]

Picked and pushed to master through 3.0. Thanks, all!

[Blake GH (bmagic)]

Upgraded to 3.0.9 July 4th. We are still seeing transit slips getting printed with the wrong information. The second scan results in the correct information.

[Kathy Lussier (klussier)]

Hi Blake,

Since this bug already has a status of Fixed Released, I recommend that you submit a new bug about this issue. Otherwise,it will be difficult for people to find your report.