Location Consent Service

Location Consent Service has medium complexity but carries disproportionate risk to the project because every location-related feature depends on it being correct and thoroughly tested. It spans both mobile and backend execution contexts, which means coordination between the mobile and backend teams is required during development and testing. The revoke-and-delete flow needs explicit end-to-end testing to confirm that location data is actually purged from the database upon revocation — not just flagged. Privacy-related functionality typically attracts additional scrutiny from stakeholders and legal reviewers, so budget time for a dedicated privacy review pass.

Delays here will cascade to the Mentor Location Service and the map feature as a whole. Document the consent audit log schema early to avoid late-stage database changes.

Location Consent Service manages ConsentRecord lifecycle operations via the Mentor Location Repository, which handles the actual Supabase upsert and read operations. The hasConsented check must be called before any spatial read in the Mentor Location Service — enforce this contract at the service boundary, not via documentation alone. The revokeConsent flow must atomically call deleteLocation on the repository in the same transaction or with compensating logic to avoid a state where consent is revoked but location data remains. Implement getConsentRecord to return null rather than throwing on missing records to simplify upstream null-check patterns.

The audit timestamp should be server-generated (Supabase now()) rather than client-generated to prevent clock skew inconsistencies across devices. Consider caching hasConsented results with a short TTL to reduce redundant database reads on high-frequency map refreshes.