https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43082 Bug ID: 43082 Summary: Flaky action_logs.t object filter test due to default LIKE matching Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris@bigballofwax.co.nz Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org Target Milestone: --- This patch fixes an intermittent failure in t/db_dependent/api/v1/action_logs.t. The 'object filter returns rows for object 42' assertion queries the REST API with ?object=42. Koha's REST API defaults every typed query parameter, including integer columns, to _match=contains, which builds a LIKE '%42%' query (Koha/REST/Plugin/Query.pm). This means the filter also matches any object value that merely contains "42" as a substring, e.g. 420, 142, 1042. The test's own fixture data uses a dynamically assigned patron borrowernumber (auto_increment, never reset by transaction rollback) as the object value for other rows logged in the same subtest. When that value drifts into a range containing "42" as a substring during a full CI run, the assertion intermittently counts an extra row and fails, even though the test passes reliably in isolation. The fix adds _match=exact to the object filter request, matching the test's actual intent of an exact object id match. Test plan: 1. Run prove t/db_dependent/api/v1/action_logs.t - it passes. 2. To see the underlying bug, insert an action_log row with object 42 and another with object 420, then query GET /api/v1/action_logs?object=42 without _match=exact - both rows are incorrectly returned. 3. Apply the patch and repeat step 1 - only the exact-match row is expected and returned. -- You are receiving this mail because: You are watching all bug changes.