https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42383 --- Comment #134 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 209812 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=209812&action=edit Bug 42383: (QA follow-up) Handle HoldsAutoFill errors on check-in When HoldsAutoFill is enabled, POST /checkins calls confirm_hold on the new checkin without catching its exceptions. If the hold was cancelled or filled in the meantime (Koha::Exceptions::Checkin::HoldNotFound), or the item was checked out again (ItemCheckedOut), the request fails with a 500 and no explanation, even though the item has already been returned. The holds queue update and the bundle verification that come after it are skipped too. This patch addresses point 1 of comment #77. As the return has already happened, failing the whole request would be misleading: the check-in is kept and the outcome is reported as a 'hold_auto_fill_failed' warning message on it, with the same error_code values the hold_confirmation endpoint uses (hold_not_found, item_checked_out) and the reserve_id. The rest of the post-return processing runs as usual. Unexpected exceptions are still rethrown and rendered as a 500. The check-in page displays the warning, and does not open the hold modal for that check-in as there is no hold left to confirm. The new message is documented in the checkin definition. Test plan: 1. Run: $ ktd --shell k$ prove t/db_dependent/api/v1/checkins.t => FAIL: The 'add - HoldsAutoFill failure' tests fail, the check-in returns 500 2. Apply this patch 3. Run: k$ yarn api:bundle k$ restart_all k$ prove t/db_dependent/api/v1/checkins.t => SUCCESS: Tests pass! 4. Sign off :-D Assisted-by: Opus 5.5 (Anthropic) -- You are receiving this mail because: You are watching all bug changes.