2 Commits

Author	SHA1	Message	Date
Krzysztof kuhy Rudnicki	e7fa7fb44c	Let the PC see phone workouts again, and stop losing progression on reinstall ... A real StrongLifts session on 2026-08-10 never reached this machine, so it had to be logged as a manual workout -- spending a manual budget slot on a workout that was genuinely verified. The session was in Firebase the whole time; four separate defects each hid it. - pull_synced_workout() read a hardcoded devices/phone/log.json. Since ffc6c72 the phone pushes under a per-install uuid, so that directory has been frozen since 2026-07-17 and the PC kept returning a stale session from 07-27 as if it were current. Both readers now walk EVERY device directory; reinstalls keep minting new ones, so no single path can be right for long. - A session is identified by SHAPE (it has `exercises`), not by a `kind` field the phone never writes. That filter is why the one reader that did walk every directory discarded real sessions, and it also kept PC-origin runnerup/phone_verified records from being handed to a caller expecting a session. - FirebaseSyncError is a SIBLING of GitHubSyncError, not a subclass, so `except GitHubSyncError` never caught it and a DNS failure took the whole locker down (status=1/FAILURE, then a restart loop). Catch the common parent; a pull failure degrades to a warning. - A GitHub token is no longer required to sync. Firebase has been primary since eb4ff01, so a Firebase-only machine was reporting "sync is OFF" while syncing fine. Sync also only ran once per locker start, so a workout finished after login was invisible until the next login. workout-sync.timer runs the new headless --sync-only every 15 minutes; remove_systemd.sh now removes every unit the installer creates, not just two of them. workout_app: the 2026-08-05 reinstall wiped progression because the DB seeds factory defaults before the backup is restored, and the first write then exported those defaults over the only off-device copy. Storage permission is now settled before the DB opens, a defaults-only DB refuses to overwrite a richer backup, and the three swallowed storage errors say what broke. Sessions that exist only in Firebase/GitHub are restored into local history, so a reinstalled app has the history it actually earned rather than starting at whatever survived. Matched on (date, start_time), so re-syncing never duplicates and local rows always win. Adds a target-reps editor: progression can only ever RAISE reps, so a rep target a defaults re-seed set wrong could not be corrected from the UI at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JS5V44jkHZiH1wC7BH5h5n	2026-08-10 14:39:02 +02:00
Krzysztof kuhy Rudnicki	b0d9165a79	Retry sync past the boot/resume network race, and stop blaming the token ... The morning routine is started by systemd right after boot and right after resume, so its sync ran seconds before DHCP/DNS were up. Every such run failed outright — and said this: Workout sync push FAILED for 6 workout(s): network error reading screen-locker-sync/devices — a 403 here means the token lacks contents:write on kuhyx/syncs Both halves of that were wrong. It was not a 403, and the token was fine: the same six workouts pushed successfully by hand minutes later on the same token, which reports push=true on the repo. The message cost a real investigation chasing a permissions bug that did not exist. - _sync_retry.with_sync_retry wraps the three sync call sites in a bounded retry (4 attempts, 2s/4s/8s backoff — ~14s, enough for the network to come up, short enough not to drag the routine). Verified offline in a network namespace: three retries, then an honest give-up. - Any GitHubSyncError retries, deliberately including RepoNotFoundError. Classifying transient vs permanent would couple us to which exception crdt_sync chains where; a few wasted seconds on a genuinely bad token is the cheaper mistake. - The push failure log now reports what actually happened. The contents:write hint survives only for RepoNotFoundError, which is the one error that actually implicates the repo or the token. Retry at the application layer rather than ordering the unit after network-online.target: the same race hits on resume, where boot ordering does not apply, and these are user units that cannot depend on a system target. The tests' autouse no-sleep fixture patches the module-local `sleep` name rather than `_sync_retry.time.sleep` — the latter mutates the shared time module object and silently disabled sleep for the whole suite, breaking an unrelated temperature timeout test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 08:46:37 +02:00