Description
Added Sync Diagnostics to help identify how much data was saved locally, uploaded, downloaded, skipped or failed, along with available reasons. The feature is integrated with release-2.4.

1. Open Sync Dashboard

Select a village and open Sync Dashboard. Three tabs are available: Status, Logs and Summary.

2. Status Tab

Shows module-wise sync status, overall progress, worker status and records requiring attention.

QA: Verify status updates after saving/syncing and that existing retry functionality works correctly.

3. Logs Tab

Shows manual-refresh and direct-save activity. Manual refresh includes both PUSH and PULL activity when executed.

API entries provide available request/response details, HTTP status, timing and correlation IDs. Sensitive fields are masked. Tap an entry to inspect details.

QA: Verify successful and failed requests are understandable. Auto-sync noise must not appear in the interactive logs/shared interactive log report. Background auto-sync itself should continue working.

4. Summary Filters

Today is selected by default. Users can select Yesterday or All, then switch between PUSH and PULL.

Refresh Summary updates the displayed information; it does not itself start a sync.

QA: Verify filters, tab selection, scrolling and refreshed results.

5. Village-Wise Existing Data

“Available in village DB (all dates)” shows current records available locally for the selected village, including existing/downloaded and newly saved data.

It is independent of Today/Yesterday/All. Counts are module records, not unique patients; drafts/deactivated records are excluded.

QA: Switch villages and verify another village’s records are not included.

6. PUSH Flow

Save or update a record locally, then upload it through direct-save sync or manual refresh.

The overall summary and module charts show:

Saved locally = Synced + Failed + Pending.

Server downloads must not increase local-save totals. Retries must not duplicate unique-record counts.

QA: Save records in different modules, verify pending status, upload them and verify counts. Edit an already-synced record and confirm it is not incorrectly treated as synced before its newer changes upload.

7. PUSH Failure Details

An affected module provides View Failures, showing available record identifiers, failure time and reason.

Last Failed Sync provides historical failure information. A successful retry can resolve the current record status while historical failure evidence remains.

QA: Trigger a controlled failure, inspect its reason, retry successfully and verify the distinction between historical failure and current status.

8. PULL Flow

Select PULL to inspect the selected available sync run. Module cards show reported Saved to DB, Skipped and Failed counts.

View Skips explains blocking cases where incoming data could not be applied, such as a missing local beneficiary or protected pending edits. Already-up-to-date records should not appear as blocking failures.

QA: Verify valid downloads, missing-beneficiary cases and malformed OPD records. One invalid OPD record must not prevent later valid records from processing or replace existing prescriptions.

9. Camp Connection History

Shows the current hub/IP, separately labelled port, connection status, last check, last connected/disconnected times and detected disconnect reason.

Counts increase on observed state transitions, not every repeated check. The first observation establishes a baseline. Unreachable is part of Disconnected, not an additional event to add to it.

QA: Disconnect/reconnect Wi-Fi and verify counts, timestamps and reasons. A connected hub must not automatically imply all APIs succeeded.

10. Hub Address History

Retains known hub addresses, recorded address changes and available per-hub connection history.

Camp history is tablet-wide across villages. Patient inventory and PUSH/PULL information remain village-wise. Legacy/partial history is labelled accordingly.

QA: Change hubs, switch villages and verify previous hub history remains available without mixing patient counts.

11. Sharing

Share is available from Logs and Summary. The dialog offers Logs and Summary checkboxes.

The current page’s option is selected by default. Users can share either section or both in one export.

QA: Verify all three combinations, exported contents, readable failure/skip details and sensitive-field masking.

12. Persistence and Regression

Tracked PUSH daily history and Camp history should survive normal app restarts. PULL run history is session-based; unavailable historical information must not be shown as zero.

QA: Upgrade without clearing app data and verify existing records, migrations, save/view flows, prescriptions, sync and reconnect behavior. Check for crashes, ANRs and layout clipping while sync runs.