Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

aw-sync: duplicate folders for one device_id silently truncate history on pull

Aperta
#683 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
backend, databases

Direzione di ricerca

Start with sync_one() in aw-sync/src/sync.rs and compare its resume logic with sync_wrapper::pull(), then trace get_or_create_sync_bucket() and the discovered remote folders. The fix is done when multiple folders for one device_id cannot silently truncate history, skipped sources are clearly warned about, and provenance or resume behavior is safe against hostname changes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

When one physical device has written under two different folder names in the sync directory, pull_all imports both. Because provenance is derived from the bucket's hostname field rather than the folder name, both folders resolve to the same destination bucket — and the resume logic then silently discards most of the history.

Whether you lose data depends on fs::read_dir ordering, which is arbitrary.

Mechanism

sync_one() (aw-sync/src/sync.rs) picks its resume point from the newest event already in the destination:

let resume_sync_at = most_recent_events
    .first()
    .map(|e| e.timestamp + e.duration)
    .or(sync_spec.start);

and then only fetches events newer than that from the source. So if a folder holding a short, recent slice of history is imported before the folder holding the full history, the resume boundary jumps forward and everything older in the good database is never fetched. Re-running sync does not recover it — the boundary is now baked into the destination bucket. Only deleting the destination bucket and re-pulling recovers the data.

sync_wrapper::pull() already guards against this within a single folder:

if dbs.len() > 1 {
    warn!("More than one db found in sync folder for host, choosing largest db {:?}", dbs);
}

but there is no equivalent check across folders, and nothing anywhere keys on device_id.

Real-world instance

One Android device, two folders, same device_id (41662faa-…), identical hostname on every bucket row inside both databases ("POCO F8 Ultra"):

folder size aw-watcher-android events range
POCO F8 Ultra/ 9.4 MB 4,068 2026-07-02 → 2026-07-18
poco_f8_ultra/ 273 MB 1,027,343 2021-05-18 → 2026-09-14

Both import into aw-watcher-android-synced-from-POCO F8 Ultra. If the 9.4 MB folder is walked first, the resume boundary becomes 2026-07-18 and the entire 2021–2026 history is skipped — ~1M events, silently, with ✓ Already up to date! in the log. aw-watcher-android-unlock (98,035 vs 100,188 events) truncates the same way.

The two folders exist because aw-android started sanitizing the device hostname (see the companion aw-android issue), but this is not Android-specific: any hostname change, re-install, or manual folder rename reproduces it.

Suggested fix

  1. Deduplicate by device_id before importing. Group the discovered remotes by the device_id path component; if a device_id appears under more than one folder, use one (largest, or newest last_updated) and warn! naming the folders that were skipped. This alone removes the hazard and would have caught the case above automatically.
  2. Make device_id the provenance key, not hostname. get_or_create_sync_bucket() currently derives origin from $aw.sync.origin → falling back to bucket_from.hostname; neither is stable across a rename, and both are decoupled from the folder the data actually came from.
  3. Refuse to regress the resume boundary. If a source database's newest event is older than the destination's, that source has nothing to contribute — but if its oldest event is older than the destination's oldest, it holds history the destination lacks. Backfilling that case (or at minimum warning loudly about it) would make the operation safe regardless of ordering.

Discovered alongside the daemon layout bug filed separately; both were hit in the same setup.

cc @TimeToBuildBob

Lingua principale
Rust
Stelle
317
Fork
99
Merge medio
1g 13h
PR unite (30g)
66

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ActivityWatch/aw-server-rust

Tutte le issue di ActivityWatch/aw-server-rust

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.