Repository navigation
Strap sync not working after switch from 8.2.2 on 4.0 #57
Description
NOOP version
8.3.4
Platform
Android
OS version
Android 18
WHOOP strap model
WHOOP 4.0
Where the data is coming from
Live Bluetooth (strap connected)
Test Centre profile
Not a test-mode bug
What happens
After switching from 8.2.2 and loading backup i saw a now history error telling me to remove the whoop and reconnect, after reconnecting a few times syncing stays on 0 (I do see live HR streaming)
What you expected instead
It syncs stored records or gives me an error
Steps to reproduce
1.load backup from 8.2.2
2.connect whoop
3.remove and reconnect whoop
noop-strap-log-260707-1946.txt
Strap log
Strap log attached
Before you submit
- I attached my exported NOOP .zip (not a screenshot of the Live screen). If my bug is a clearly reproducible UI issue I described exactly how to see it instead.
- I attached or pasted a strap log above — or my bug is a clearly reproducible UI issue that doesn't need one (e.g. a typo, a button that does nothing) and I've described exactly how to see it.
- I checked the Troubleshooting guide — especially "history syncs but no data" (most often the strap isn't banking history to flash; charge it to 100% and reconnect).
- I checked the FAQ and — if I'm on a WHOOP 5.0 / MG — the 5.0/MG status page, and this isn't an already-known limit (e.g. SpO₂, or recovery/sleep on the 5/MG).
- I've left out anything personal (strap serial, account email, raw export).
Activity
ryanbr commentedon Jul 8, 2026
Thanks for the log — this is a real bug on our end, not your strap, and I've fixed it.
What happened: loading a backup swaps the database file, which requires a full app restart. NOOP only showed a dismissable message about that, so when you kept the app open and connected the strap, every write failed with "connection pool has been closed" — the app was still writing to the old, closed database. That's why sync sat at 0 while live HR (which doesn't touch the database) kept working.
The fix (in the next build): NOOP now automatically restarts after a restore instead of relying on you to do it, and — importantly — it will no longer advance the strap past history it couldn't store (a second bug that was discarding records during the broken window).
What to do now:
One honest note: some history that the strap offloaded during the broken window may have been trimmed from the strap before we could store it — that portion may be gone. But your restored backup data (from 8.2.2) is intact, and the strap will bank and sync new data normally from here. Charging the strap to 100% and reconnecting is worth doing (your log also shows a future-dated strap clock, which can hold back older ranges — a full charge + reconnect usually settles that).
Let me know how it goes after the force-stop + reopen.
Backfill: mirror the persist-stall ack guard to iOS + make the restor…
kavemang commentedon Jul 8, 2026
After a force stop its showing history as syncd
Debug export: surface strap-write health + last restore (#57 observab…
Merge pull request #62 from ryanbr/fix-restore-closed-db
Backfill/Restore: don't sync into a dead DB after a backup restore, a…
Fix(audit): backup auto-restart, BLE ts bound, Direct Boot, local sig…
ble: surface unauthorized/off/unsupported Bluetooth instead of a sile…
Backfill/Restore: don't sync into a dead DB after a backup restore, a…
Backfill: mirror the persist-stall ack guard to iOS + make the restor…
Debug export: surface strap-write health + last restore (ryanbr#57 ob…
Merge pull request ryanbr#62 from ryanbr/fix-restore-closed-db
ble: surface unauthorized/off/unsupported Bluetooth instead of a sile…
sleep stages: label the night carousel by calendar nights, not record…
feat(backup): save custom journal behaviours to the .noopbak (#1361)
feat(backup): save custom journal behaviours to the .noopbak (#1361)
ble: surface unauthorized/off/unsupported Bluetooth instead of a sile…
sleep stages: label the night carousel by calendar nights, not record…
Last sync belongs to a strap, not to the install (#1745)
apple: keep the global writes the prefs-only header still reads
Apple parity: last sync belongs to a strap, and sync controls follow …