https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42769
Martin Renvoize (ashimema) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43848 --- Comment #26 from Martin Renvoize (ashimema) <[email protected]> --- Created attachment 208462 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208462&action=edit Bug 42769: (QA follow-up) Run the SIP2 message tester in isolation and clean up after it Running the real SIP handlers has effects that rolling back the database transaction does not undo, and the way the state was restored could hide a failure: - The state was restored, and the transaction rolled back, in a Try::Tiny finally block. An exception thrown there is swallowed, so a rollback that failed could leave the changes of a checkout or checkin in place and still answer 200. Restore the state with plain statements and roll back in a try of its own, so a failed rollback is thrown. The transaction is also begun before any global is touched. - Enqueuing a background job publishes it to the message broker straight away, a rollback doesn't recall it and the workers hear about jobs that never existed. Publishing is suppressed while the handler runs. - update_lastseen stores the date, which is rolled back, and remembers in the cache that it did so for the day, which is not, so a real connection afterwards would skip the update. It is turned off while the handler runs. - The handlers ran with the session of the staff member running the test. They now run with the session a real SIP login has, the patron the account logs in as at the institution's library, which the circulation rules read. The test fails with ObjectNotFound if that patron doesn't exist, as a login would. The access check still runs first, with the session of the staff member. - Every test is logged, outside the transaction, with the user, the account and the message code ( no patron or item identifiers ). Rolling back also means a failed patron password check leaves no trace. The line goes to the api log without the plack- prefix that Koha::Logger adds under Plack, as the default configuration only logs plack-api from WARN and an INFO line would be dropped for every request the web server handles. - The POD and the API description no longer say that nothing is changed: plugin hooks still run and the password lockout does not apply. To test: 1) prove t/db_dependent/Koha/SIP2/MessageTester.t 2) prove t/db_dependent/api/v1/sip2_account_test_message.t Signed-off-by: Martin Renvoize <[email protected]> Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43848 [Bug 43848] Share SIP request parsing and building between server, emulator and tester -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
