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:
parent
bbc0124ede
commit
5799159034
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue