Register DistancePrefillService Riverpod provider
epic-mileage-reimbursement-entry-data-layer-task-008 — Expose DistancePrefillService as a Riverpod provider. Wire the auth session stream listener so clearOnLogout is called automatically on sign-out without requiring manual invocation from UI layer. Verify the provider is disposed correctly on auth state change.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Pattern: create a Notifier or use a plain Provider with a ref.onDispose block. Use Riverpod's ref.listen to watch an authStateChangesProvider (a StreamProvider wrapping supabase.client.auth.onAuthStateChange). In the listen callback, check if the event is AuthChangeEvent.signedOut and call service.clearOnLogout(previousUserId). Store the previous userId by reading the current session before the sign-out event clears it.
If using a Notifier, the build() method initialises the stream watcher via ref.listen. Avoid using keepAlive() unless the provider is explicitly required to persist — prefer letting the provider tree manage lifecycle naturally.
Testing Requirements
Unit tests (flutter_test with ProviderContainer): verify distancePrefillServiceProvider resolves without error; verify that simulating a sign-out event via a fake auth state stream causes clearOnLogout to be called on the fake DistancePrefillService (use a spy/mock); verify that provider disposal cancels the stream subscription (check that the fake stream's cancel callback is invoked). Use ProviderContainer with overrides for all dependencies.
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.