Skip to content
FRA Flow
Menu
SoftwareBS 9792AppPricingAssessorsToolsDocs
Try FRA Flow freeTalk to usLog in

Sync is stuck

How to diagnose and clear a sync queue that has stopped draining after coming back online.

By Richard Pryce·Last updated

Most syncs drain in seconds. Occasionally a queue gets stuck: the device shows "n pending" indefinitely, or a specific observation never picks up its server id. This page is the diagnostic flow.

What "stuck" looks like

Three usual symptoms:

  • The sync indicator at the top of the workbench shows a pending count that does not decrement.
  • Observation cards show the "Local" pill long after you reconnected.
  • The reviewer queue / dashboard shows assessments without observations that you definitely captured.

Any of those is the cue to run through the steps below.

Step 1. Confirm you actually have a network

Open Safari (or another tab) and load any page. If it loads, the device has a working connection. If not, the queue is correctly waiting; reconnect first.

The device sometimes shows "online" while sitting on a captive-portal wifi (hotel, conference centre) that requires a sign-in tap. If you see a captive-portal page when opening a tab, sign through it; the queue resumes.

Step 2. Force a drain

Pull-to-refresh the workbench. The sync triggers handler fires on visibility changes and on pull-to-refresh; either nudges the drain.

If the count drops, you are done.

Step 3. Check the failed-row indicator

The sync queue retries failed mutations with backoff. After several failed attempts a row is marked failed and stops draining. The sync indicator surfaces this with a small warning icon.

Tap the indicator. The expanded panel lists failed rows. Each row has a one-line error. Common causes:

  • Auth expired: sign out and sign back in.
  • Conflict on server: the server already has a row with the same id (typically a duplicate from a parallel device). The drain retries on each fresh load, so this often clears itself.
  • Unknown 5xx: provider blip. Tap Retry on the row.
  • FK violation: rare, usually caused by deleting a location while observations against it were still in the queue. Manual fix is to delete the orphan observation from the workbench.

Step 4. Hard reset (last resort)

If the queue is genuinely stuck and Steps 1 to 3 have not helped:

  1. Sign out and sign back in (drops the local IDB cache).
  2. Re-preflight the assessment from the visit list.
  3. Re-capture any unsynced observations.

This is destructive of any unsynced local-only observations, so it is the last resort. Before doing it, confirm with a sync indicator screenshot that nothing important is pending; the sync panel lists every queued mutation.

When to escalate

If the same row keeps failing after Steps 1 to 3, send us the sync indicator's failure snippet plus the assessment id. Most stuck-row patterns we have seen are fixable on the server side in a few minutes; a hard reset is rarely needed.

Where to go next

Next

Photo did not classify →