Summary
The scheduled mutation-testing run on 2026-07-17 (run 29575897246, commit range covering backend/src/inbound/http/users.rs and related test files) tested 78 mutants: 1 missed, 3 caught, 74 unviable. This is wildside's first survivor-harvested mutation run, so the one surviving mutant below is the initial finding to triage.
Survivor
backend/src/inbound/http/users.rs:71:41 — in parse_interest_theme_ids:
if payload.interest_theme_ids.len() > INTEREST_THEME_IDS_MAX {
return Err(InterestsRequestError::TooManyInterestThemeIds { .. });
}Mutation: replace > with >=. The full workspace test suite (694 library tests plus integration suites) passed unchanged against the mutant, meaning no test exercises the boundary where interest_theme_ids.len() == INTEREST_THEME_IDS_MAX. With >= substituted, a request supplying exactly the maximum permitted number of interest theme identifiers would be wrongly rejected as TooManyInterestThemeIds, but no test catches this behavioural change.
Proposed next step
Add a boundary-value test (e.g. in backend/src/inbound/http/users.rs's test module or the users_list_pagination_bdd/interests request-validation suite) that submits exactly INTEREST_THEME_IDS_MAX interest theme identifiers and asserts the request is accepted, alongside the existing "one over the limit" rejection test (update_interests_rejects_too_many_ids / interests_request_validation_rejects_too_many_ids) so the > boundary is pinned down in both directions.
Reference
Summary
The scheduled mutation-testing run on 2026-07-17 (run 29575897246, commit range covering
backend/src/inbound/http/users.rsand related test files) tested 78 mutants: 1 missed, 3 caught, 74 unviable. This is wildside's first survivor-harvested mutation run, so the one surviving mutant below is the initial finding to triage.Survivor
backend/src/inbound/http/users.rs:71:41— inparse_interest_theme_ids:Mutation: replace
>with>=. The full workspace test suite (694 library tests plus integration suites) passed unchanged against the mutant, meaning no test exercises the boundary whereinterest_theme_ids.len() == INTEREST_THEME_IDS_MAX. With>=substituted, a request supplying exactly the maximum permitted number of interest theme identifiers would be wrongly rejected asTooManyInterestThemeIds, but no test catches this behavioural change.Proposed next step
Add a boundary-value test (e.g. in
backend/src/inbound/http/users.rs's test module or theusers_list_pagination_bdd/interests request-validation suite) that submits exactlyINTEREST_THEME_IDS_MAXinterest theme identifiers and asserts the request is accepted, alongside the existing "one over the limit" rejection test (update_interests_rejects_too_many_ids/interests_request_validation_rejects_too_many_ids) so the>boundary is pinned down in both directions.Reference