Also need to consider renewals...
Overview: Although check out is a multi-step process that includes changing an item's status, creating a loan object, and possibly other actions such as emailing a receipt to the patron and/or publishing an Event Message in PubSub, from the point of view of an application making a single request to the checkout-by-barcode endpoint it is an atomic operation performed in a single request. At present, checkout-by-barcode returns the status of the final step in this pipeline, which may be a failure, even if early steps in the pipeline (such as changing the item status and creating the loan) succeed. This is misleading, if not downright wrong, and it causes the UI to indicate that the operation failed when in fact a loan was created for the item and patron.
Expected Results: If an item's status changes from 'Available' to 'Checked out' and a loan item is created, the response-code should be a 200, even if other portions of the check out process fail and return 500.
Actual Results: If an item's status changes from 'Available' to 'Checked out' and a loan item is created, but later portions of the check out process fail, the response-code is that of the failed portion of the check out.
Additional Information: Related details/discussion at
CIRC-1045; Mockup from Kimie Kester: https://drive.google.com/drive/folders/1OpAPctJJQWs72leqsSwHjRBfo-ZGlxzs?usp=sharing