Register MileageClaimRepository Riverpod providers
epic-mileage-reimbursement-entry-data-layer-task-006 — Create Riverpod providers for MileageClaimRepository, including a family provider for user-scoped claim lists and a coordinator-scoped provider. Wire invalidation logic so claim list providers refresh after successful insert or status update operations.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Use Riverpod code generation (@riverpod annotation) if the project already uses riverpod_generator for consistency. Define UserMileageClaimsNotifier as an AsyncNotifier that calls repository.fetchByUser() in build(). Expose an insertClaim(MileageClaim) method on the notifier that calls the repository and then calls ref.invalidateSelf(). For coordinator provider, expose updateStatus(String claimId, MileageClaimStatus status) which invalidates both coordinator and user providers after success.
Avoid watching the repository provider inside a family notifier build — read it once in the method calls to prevent unnecessary rebuilds.
Testing Requirements
Unit tests (flutter_test with ProviderContainer): verify mileageClaimRepositoryProvider resolves to the correct concrete type; verify userMileageClaimsProvider returns AsyncData with the list from the repository fake; verify that calling insert on the repository notifier causes userMileageClaimsProvider to rebuild (use a listener or read the provider twice and confirm re-fetch). Use a ProviderContainer with overrides to inject a fake MileageClaimRepository.
If OrgRateConfigRepository caches the per-km rate aggressively and an admin updates the rate mid-session, ongoing form interactions will show the old rate until the Stream emits. This could result in the UI showing a rate that differs from what is stored when the claim is submitted, causing confusion or disputes.
Mitigation & Contingency
Mitigation: Subscribe to a Supabase Realtime channel for the org_configuration table so config changes propagate within seconds. Document the eventual-consistency window in code comments.
Contingency: If Realtime subscription proves unreliable in test, add a polling fallback with a configurable interval (default 5 minutes) and display a 'rate updated' toast when the stream emits a changed value.
The correction window within which a claim can be deleted or voided is not explicitly specified in the feature documentation. Implementing the wrong window (e.g. 24 hours vs 7 days) could lock users out of corrections or allow inappropriate post-approval modifications.
Mitigation & Contingency
Mitigation: Raise the correction window definition as a blocking question to the HLF product owner before implementing the delete/void path in MileageClaimRepository. Implement the window duration as an org-level configuration value rather than a hardcoded constant.
Contingency: If the question cannot be resolved before implementation, default to 24 hours as the most conservative option and flag the value for review in the first user-acceptance test.