Bug 43082: Fix flaky object filter test in action_logs.t

The default `_match=contains` matching builds a LIKE query even on
integer columns, so a plain `?object=42` also matches object values
like 420 or 142. The test's dynamically-assigned patron borrowernumber
(auto_increment, never reset by transaction rollback) could drift into
a value containing "42" as a substring, intermittently inflating the
match count in CI. Add `_match=exact` since the test's intent is an
exact object id match.

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
This commit is contained in:
Martin Renvoize 2026-07-15 13:46:19 +01:00 committed by Pedro Amorim
parent bbc0124ede
commit 5799159034
No known key found for this signature in database
GPG Key ID: 06B75BA7F3894D55
1 changed files with 4 additions and 1 deletions

View File

@ -136,7 +136,10 @@ subtest 'q DSL: multi-value, like, range' => sub {
is( scalar @{ $t->tx->res->json }, 2, 'like operator on info matches both biblio rows' );
# Object filter via typed param
$t->get_ok("//$userid:$password@/api/v1/action_logs?object=42")->status_is(200);
# _match=exact is required: the default 'contains' matching does a LIKE
# match even on integer columns, so plain ?object=42 would also match
# object values like 420 or 142.
$t->get_ok("//$userid:$password@/api/v1/action_logs?object=42&_match=exact")->status_is(200);
is( scalar @{ $t->tx->res->json }, 2, 'object filter returns rows for object 42' );
# Combined filter