Propagate patient update save failures from cloud sync

[tamtam888]

Context

During PR #60 review, we checked whether onUpdatePatient can be awaited to detect consent-save failures.

Finding:

• PatientDetailsPage.jsx receives onUpdatePatient from patientsState.handleUpdatePatientInline.
• handleUpdatePatientInline is async, but the current save chain does not propagate Supabase/cloud sync failures to the caller.
• Cloud upsert errors are logged and handled internally, but not surfaced to UI code.

This means adding try/catch around await onUpdatePatient(...) in a component would create fake error handling: it would not catch real Supabase failures.

Problem

Patient update flows can appear successful locally even if cloud persistence fails or is retried silently.

This affects video consent and may affect other patient update fields, not only consent.

Goal

Create a clear, reliable way for patient update callers to know whether cloud persistence succeeded, failed, or is pending.

Possible approaches

• Return a result object from patient update functions, such as { localSaved: true, cloudStatus: "queued" | "synced" | "failed" }.
• Surface sync failure through a central notification/toast system.
• Track per-patient pending cloud sync state.
• Avoid implying full cloud save success when only local state was updated.

Out of scope

• Do not change video consent logic in PR Add video consent gate for patient media workflows #60.
• Do not add legal/compliance claims.
• Do not implement audit history or digital consent here unless separately scoped.

Related

Follow-up from PR #60: video consent gate for patient media workflows.

[tamtam888]

Architecture review for Issue #61 - patient update cloud save status

Claude Code completed a read-only architecture review of the current patient update save flow.

Current save flow

Patient update flow:

1. Caller uses onUpdatePatient(updatedPatient).
2. App.jsx passes patientsState.handleUpdatePatientInline.
3. handleUpdatePatientInline calls handleUpdatePatient(updatedPatient).
4. handleUpdatePatient performs validation, updates local state/local persistence, then calls enqueueCloudUpsert(...).
5. enqueueCloudUpsert(...) performs debounced Supabase upserts.

Current failure behavior

• Local persistence errors are swallowed.
• Supabase upsert errors are logged and re-queued internally.
• No success/failure/pending status is returned to the caller.
• Components cannot reliably detect whether cloud persistence succeeded or failed.

Risk

For current single-device pilot use, the risk is lower because optimistic local updates work immediately.

For multi-device use or poor connectivity, the risk is meaningful:

• A therapist may believe a patient update or consent update was saved.
• Another device may not reflect that update if cloud sync failed.
• Consent records are especially sensitive to this ambiguity.

Recommended minimal implementation

Add patient-level cloud sync status to usePatients:

• idle
• pending
• ok
• error

Set status in enqueueCloudUpsert:

• when a patient update is queued: pending
• when Supabase upsert succeeds: ok
• when Supabase upsert fails: error

Expose a selector from the hook, for example:

cloudSyncStatusFor(idNumber)

Then wire it through App.jsx to PatientDetailsPage.jsx and show a small inline indicator:

• Syncing...
• Saved
• Sync failed - changes are saved locally

Proposed files to change

• src/hooks/usePatients.js
• src/App.jsx
• src/pages/PatientDetailsPage.jsx
• src/pages/PatientDetailsPage.css
• src/i18n/translations.js

Postpone

• manual retry button
• global offline banner
• IndexedDB failure surfacing
• extending notificationsStore
• audit trail / consent history
• revoke consent confirmation dialog

PR strategy

Recommended as one narrow PR, because the hook, App wiring, UI display, CSS, and translations are one cohesive change.