Implement ContactSearchService local in-memory filtering
epic-contact-list-management-business-logic-task-004 — Build the local in-memory search path in ContactSearchService for datasets below the configurable size threshold. Implement substring matching across contact name and notes fields. Apply query string normalization (trim, lowercase, Unicode normalization) before comparison to ensure consistent case-insensitive matching. Define and expose the configurable threshold constant.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Use `String.toLowerCase()` for lowercasing — Dart's toLowerCase() is locale-aware for ASCII but for Norwegian characters it is safer to normalise to NFC first using the `characters` package or `String.runes`. Consider using the `diacritic` pub package if full Unicode folding is needed, but for Norwegian (ø→ø, æ→æ, å→å) simple toLowerCase() after NFC normalisation is sufficient since these characters do not decompose under NFC. The local filter should be a pure function `List
Do not use RegExp for substring matching — `String.contains()` is sufficient and avoids regex injection risk.
Testing Requirements
Pure unit tests (flutter_test) with no mocks needed — local filtering is deterministic. Create a fixture list of 10–20 Contact objects covering: ASCII names, Norwegian names (ø/æ/å), contacts with null notes, contacts with notes containing keywords. Test each acceptance criterion as a separate test case. Verify the threshold constant is accessible and has the correct default value.
No widget tests or integration tests required at this layer.
For organizations with large contact lists (NHF has 1,400 local chapters and potentially thousands of contacts), local in-memory filtering may be too slow and Supabase ILIKE queries without supporting indexes may exceed acceptable response times or accumulate excessive read costs, degrading search usability for power users.
Mitigation & Contingency
Mitigation: Define and document the list-size threshold in ContactSearchService before implementation. Confirm that indexes on name and notes columns exist in the Supabase schema before enabling server-side search. Profile ContactSearchService against realistic data volumes in the staging environment using the largest expected org.
Contingency: If response times are unacceptable in staging, introduce result-count pagination in ContactListService and add a user-visible 'showing top N results — refine your search' indicator, deferring full pagination to a follow-up task.
In NHF's multi-chapter context, when a user switches organization, Riverpod providers may emit a brief window of stale contact data scoped to the previous organization before the invalidation cycle completes, transiently exposing contacts from the wrong chapter.
Mitigation & Contingency
Mitigation: Model organization context as a Riverpod provider dependency so that any context change immediately marks contact providers as stale. Render a loading skeleton instead of the stale list during the re-fetch transition. Cover this scenario in integration tests with explicit org-switch sequences.
Contingency: If race conditions are observed during QA, add an explicit organization_id equality check in ContactListService that compares each fetched record's scope to the active session org, discarding any mismatched batch before returning results to the provider.