Also, we will not implement session_id at this time. We discussed it as a way to fix another potential issue found by developers (not reported by users). If two different desktops/laptops are simultaneously checking in items for the same user, when the session is closed is one machine, it's closed on both. This is true regardless of the service point too. This doesn't necessarily cause a problem - it means that if check in receipts are used, once the session is closed on the first machine, it'll send a check in receipt with items already processed from both machines. Once the session is closed on the second machine, it'll send a second check in receipt with the remaining items from the second machine. The same holds true for check out receipts. This is an edge case and probably not very likely to happen on a regular basis. However, I can see a couple of scenarios where it might happen: 1.) A patron brings up a large stack of items, and two people at two different desktops start processing their check in or out. 2.) A patron drops a bunch of items off in the overnight bin outside of the library, and a few different people process those (or different service points).

Per the sessions are now deleted when there's an error. Alex is investigating whether or not the notice errors are logged. It will be logged in the circulation log as part of .

/: We ran into this exact same situation again in couple of environments running mod-circulation-19.2.8 where several check-in/check-out patron sessions were stuck due to a loan having references to deleted items. Interested parties: /

One type of error is a missing data object reference described in (umbrella) and (specific). There may be other types of errors causing these undeleted but failed sessions. It appears that no notices are sent after a session become "stuck." If the missing data objects are the only errors causing this failure then this ticket should be closed as a duplicate.