Integrate StatsCacheManager into StatsRepository
epic-coordinator-statistics-dashboard-foundation-task-007 — Wire the StatsCacheManager into StatsRepository so all query methods check the cache before hitting Supabase and populate the cache on successful responses. Ensure cache keys are deterministic for identical query parameters. Add a force-refresh parameter to bypass cache for explicit user-triggered refreshes.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Wrap each repository method with a private _withCache
Testing Requirements
Unit tests: (1) cache hit — Supabase client never called; (2) cache miss — Supabase called once, result stored; (3) forceRefresh=true — Supabase called even when cache has valid entry; (4) Supabase error during force-refresh — original cache entry preserved; (5) identical parameters in different construction order produce same cache key; (6) RoleAccessValidator still called on force-refresh path. Use flutter_test with mock StatsCacheManager and mock SupabaseClient. Verify interaction counts with verify() matchers.
Pre-aggregated Supabase views may still be slow for orgs with very large activity datasets (NHF with 1,400 chapters). If the view query plan performs sequential scans, dashboard load times could exceed acceptable thresholds and degrade the perceived value of the feature.
Mitigation & Contingency
Mitigation: Design views with composite indexes on (org_id, coordinator_id, month) from the start. Run EXPLAIN ANALYZE during development against a seeded dataset of realistic scale. Add materialized view refresh strategy if needed.
Contingency: If live view performance is insufficient, convert to materialized views refreshed on a schedule or on activity-write triggers. Expose the refresh delay transparently in the UI with a 'last updated' timestamp.
Supabase RLS policies for the stats views may not be configured correctly during initial migration, potentially allowing cross-coordinator data leakage before the RoleAccessValidator layer is reached. This is a security and compliance risk.
Mitigation & Contingency
Mitigation: Write RLS integration tests as part of this epic that explicitly verify a coordinator JWT cannot read another coordinator's stats rows. Apply RLS policies in the migration script itself, not as a manual step.
Contingency: If an RLS gap is discovered post-deployment, immediately disable the stats screen via a feature flag, apply the corrected RLS migration, and re-enable after verification. Log and audit all queries that ran during the gap window.
Cache invalidation logic may not be triggered correctly when a new activity is registered by a peer mentor or when an expense approval is granted. Stale data could cause coordinators to make decisions based on outdated KPIs, undermining trust in the dashboard.
Mitigation & Contingency
Mitigation: Define explicit invalidation event contracts with the activity registration and expense approval pipelines. Implement an event bus subscription within StatsCacheManager. Document the invalidation contract in code.
Contingency: If event-driven invalidation proves unreliable, add a manual 'Refresh' pull-to-refresh gesture on the dashboard and reduce TTL to 5 minutes as a fallback degradation strategy.