aw-sync: the daemon (what aw-qt/aw-tauri spawn) still pulls with the 2-level walker — Android's 3-level staging is never imported, v0.14.0b7 included

[ErikBjare]

Reproduced today on erb-m2 against a desktop instance, with aw-sync built from master (b0fab73, the revision v0.14.0b7 pins).

What happens

• aw-sync status classifies the phone correctly: [peer 3-level] poco_f8_ultra/41662faa-…/test.db 299.2 MB buckets: 6 events: 1436166 imported locally: no.
• aw-sync sync (plain, no --mode) imports it — that path is sync_wrapper::pull_all → list_remote_dbs (3-level).
• aw-sync with no subcommand — the default, and exactly what aw-qt spawns (ps on the running daemon: /Applications/ActivityWatch.app/Contents/Resources/aw-sync, no args) — runs daemon() → sync::sync_run → find_remotes_nonlocal_selection → find_remotes, which is the 2-level walker ({sync_dir}/{x}/*.db). Result: Found 0 remote db files to pull, followed by the feat(aw-sync): add status doctor command and fail-loud empty-pull warnings #687 "zero peers … is usually a layout problem" warning, followed by a listing that includes the phone as a 3-level peer it did not select. Same for sync --mode pull.

So the daemon pushes every 5 minutes and never pulls an Android peer, on master. The doc comment on find_remotes says "Default-daemon pull is list_remote_dbs (3-level-only), not this function" — that is not what fn daemon does (main.rs, the sync_run call in its loop). I believe this is the original ActivityWatch/activitywatch#1445 symptom surviving every sync PR since, because each fix was verified through pull_all/status rather than through the daemon.

Invariant to enforce

Whatever status reports as a selectable peer, the daemon imports. Concretely sync_run (or daemon()) must select peers with the same list_remote_dbs + select_remote_dbs_detailed the doctor and pull_all use, keeping the legacy 2-level results as a union for old desktop peers (own-device exclusion and the #683 largest-wins dedupe already apply to both). A test that runs daemon's pass function once against a 3-level fixture and asserts the import is the regression guard — the existing tests cover pull_all, which is not the code path users run.

Side findings from the same session (separate, minor)

• aw-sync status (read-only doctor) takes the aw-sync-at-<host>-on-<port> single-instance lock, so it cannot run while the daemon is running — the one time you need it. Doctor commands should not take the daemon's lock.
• ~/Library/Caches/activitywatch/client_locks/ holds 9,012 lock files here; they are never removed.

cc @TimeToBuildBob — this is release-blocking for the "Android sync works in 0.14" story; the fix is small once the selection is shared.

[ErikBjare]

Verified end to end after filing: aw-sync sync (the pull_all path) imported the phone — 6 buckets, 1,436,166 events, totals matching the staging db exactly — into …-synced-from-poco_f8_ultra via #697's sanitized IDs. So the import machinery is sound; only the daemon's peer selection is wrong.

One more doctor defect for the same pass: after the import, status still prints imported locally: no for the phone. format_inspect (status.rs:154) checks imported_origins.contains(host) with host = the peer db's raw bucket hostname (POCO F8 Ultra), while the local suffixes are the sanitized form (poco_f8_ultra) since #697. Compare sanitize_hostname(host) as well as the raw value (raw still matters for pre-#697 imports). The has not been imported locally warning at :221 has the same bug.

[TimeToBuildBob]

Seen — this is being fixed right now (a session has a branch open, sync.rs diff in progress against aw-sync::sync).

Confirming the read for anyone else who picks this up: your proposed invariant is the right one and is not blocked on the v2 layout work. #685 (parked per ActivityWatch/activitywatch#1445) took a more invasive route — rewriting the daemon around a host-layout pull/push cycle — and got explicitly stopped so the daemon switch could land fresh against the v2 devices/{device_id}/ layout instead. What you're describing here is narrower: make sync_run/daemon() select peers via the same list_remote_dbs + select_remote_dbs_detailed that pull_all/status already use and already have test coverage for, keeping the legacy 2-level walk as a union for old desktop peers. That doesn't touch the layout or identity model #685/#302 are waiting on, so it isn't subject to the same hold.

Will also fix the two side findings noted (doctor commands taking the daemon's single-instance lock, and the unbounded client_locks growth) if they're cheap alongside this, otherwise as follow-ups.

[ErikBjare]

@TimeToBuildBob Erik's call on this one: it goes into v0.14.0b8 — he has decided against any launchd/cron workaround; the aw-sync module under aw-qt is what has to do this. So the #1445 hold is lifted for exactly the narrow change you described (shared selector in sync_run/daemon(), legacy 2-level kept as a union), and nothing broader.

Bar for the PR, so the bump can go straight in:

• one regression test that drives the daemon's pass function (not pull_all) against a 3-level fixture with an own-device 2-level root db present, asserting the peer is imported and the root db is not;
• the doctor's imported locally compare via sanitize_hostname (comment above), since status is the first thing anyone runs to check the fix;
• the lock and lock-dir findings only if trivially cheap — do not let them hold the PR.

Ping me on the PR; I will review the same hour, then bump aw-server-rust in the bundle for b8.

[TimeToBuildBob]

Opened #710 with the fix.

Root cause: used (2-level walker, visits ) while Android writes a 3-level layout (). The daemon always saw 0 remote db files for Android devices, even though and (using , 3-level) found them correctly.

Fix: when is (the daemon path), union both walkers and deduplicate — the same strategy already uses. Three regression tests added.