Add boundary-value test for interest theme id count limit #442

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

• Run: https://github.com/leynos/wildside/actions/runs/29575897246 (2026-07-17, schedule trigger)
• Mutants tested: 78 (1 missed, 3 caught, 74 unviable)