[dannash100]

Canopy has no way to tell which centrals have anyone syncing from the mobile app.

• Adds activeMobileDevices to the central's status facts: distinct mobile devices with a sync session completed in the last 30 days.
• isMobile is unindexed JSON, so a 30-day count reads every facility session of the month (5.9 GB table, 2.6 s at 60 facilities). Each sweep instead reads only sessions completed since the last one via the completed_at index, and keeps each device's last-seen in the durable check store.
• First sweep with no stored state does the full 30-day read once per central. Reads overlap by 5 min for sessions committed late.

🦸 Review Hero

• Run Review Hero
• Run Review Hero on Claude (before merge) Final review with Claude just before merging a substantive PR. Tick one or the other.

[dannash100]

🤖 QA

• Seeded sessions: each mobile device counted once, only sessions completed in the last 30 days. Open, facility and unflagged sessions excluded. Mutation-checked (dropping the mobile filter gives 4, not 2).
• Query prepares against Tamanu's real sync_sessions schema; a count under 6h old is served from cache.
• Goes out as activeMobileDevices, zero included, absent when unknown (the key canopy#679 reads).

Not yet done:

• Benchmark of the 30-day query on a big central (EXPLAIN (ANALYZE, BUFFERS) on a restored copy). No realistic data locally.
• Smoke: a release bestool on a real central shows the figure in Canopy.

[dannash100]

🤖 Benchmark of the mobile count query

Setup: M5 Mac, Postgres 16, default settings. Synthetic sessions in a session-only temp table copied from Tamanu's sync_sessions (same columns and indexes, real row shapes). Facilities sync once a minute, 300 tablets sync 6 times a day, 180 days of history. Warm cache, timings from EXPLAIN ANALYZE, 2 to 3 runs each.

Facilities	Table	Single 30-day query (first version)	Per-sweep read since last (now)	One-off backfill
10	1.1 GB	60 to 76 ms	0.02 to 0.08 ms	72 to 102 ms
30	3.0 GB	1.0 to 1.5 s, full table read	not run	not run
60	5.9 GB	2.3 to 2.6 s, full table read	0.07 to 4 ms	2.6 to 5.3 s

The single query reads every facility session in the window because isMobile is unindexed JSON; at 30+ facilities the planner reads the whole table. The per-sweep read only touches minutes of sessions through the completed_at index. All runs counted 300 devices.

Caveats:

• Facility sync every minute is assumed, not taken from Tamanu's config; a slower cadence makes every number smaller.
• Warm cache only. On a cold central the backfill will be slower than shown, once.
• Laptop, not a central's hardware or Postgres settings.

Takeaway: steady-state cost is negligible next to the existing sync_tablet_failures read (10 ms per minute at 60 facilities). The only heavy read is the backfill, once per central.