mirror of
https://github.com/kuhyx/utils.git
synced 2026-11-11 22:34:01 +01:00
Krzysztof kuhy Rudnicki
f902bbe0aa
MirrorSyncClient promised that reads consult both backends "so the cutover order is irrelevant", but every read called self.primary unguarded. A Firebase outage therefore produced no data at all and the GitHub mirror was never consulted -- the union read silently degraded to nothing, precisely when the fallback existed to help. This is not hypothetical: screen-locker's workout sync hit it on 2026-08-10, where a DNS failure reading the primary took down the whole locker rather than falling back. Reads (list_directory, get_file_text, get_string_map) now degrade to the mirror when the primary raises, and only fail when NEITHER backend can answer -- returning an empty result would be indistinguishable from "no data", which callers act on. Writes keep the old asymmetry on purpose: a write the primary did not accept has not happened, so it must still fail the tick. A mirror that cannot bulk-read (GitHub) contributes nothing but is not a failure, so it cannot by itself make a revision-map read raise. Both language ports agree on that. Same fix in the Dart port, which had all three read paths wrong too and runs on the phone. Two older tests asserted the buggy read-fail-closed behaviour and are renamed to describe what they actually exercise: the both-sides-failed case. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JS5V44jkHZiH1wC7BH5h5n |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| conftest.py | ||
| test_config.py | ||
| test_device.py | ||
| test_firebase_auth.py | ||
| test_firebase.py | ||
| test_github.py | ||
| test_hlc.py | ||
| test_log.py | ||
| test_mirror.py | ||
| test_record.py | ||
| test_store.py | ||
| test_sync_revisions.py | ||
| test_sync.py | ||