v0.14.0b3

[ErikBjare]

These are the release notes for ActivityWatch version v0.14.0b3.

New to ActivityWatch? Check out the website and the README.

Installation

See the getting started guide in the documentation.

Downloads

• Windows (.exe, installer)
• macOS (.dmg)
• Linux (.zip)

Contributors

Thanks to everyone who contributed to this release:

@0xbrayo, @ErikBjare, @TimeToBuildBob

Changelog

Changes since v0.14.0b2:

📦 activitywatch

✨ Features (1)

• feat(changelog): link previous release in 'Changes since' header (#1366) (fbd1562)

🐛 Fixes (2)

• fix(build): retry transient dmgbuild failures (#1368) (016d80b)
• fix(ci): upgrade poetry 1.4.2 -> 2.2.1 and add package-mode = false (#1365) (908b99a)

📦 aw-server

🐛 Fixes (1)

• fix(api): return inserted event with server-assigned ID from single insert; return [] from bulk (#158) (481c9a9)

📦 aw-webui

✨ Features (1)

• feat(home): engagement-gated supporter nudge + route survey/forum links through /go/ (#915) (464405d)

🔨 Misc (1)

• docs: add subscribe CTA to the Home Support section (#914) (edb7d71)

📦 aw-server-rust

📦 aw-webui

✨ Features (1)

• feat(home): engagement-gated supporter nudge + route survey/forum links through /go/ (#915) (464405d)

🔨 Misc (1)

• docs: add subscribe CTA to the Home Support section (#914) (edb7d71)

📦 aw-watcher-afk

🐛 Fixes (1)

• fix: address Greptile P2s from #82 — partial gamepad death + ambiguous log (#83) (2ee285f)

📦 aw-watcher-window

🐛 Fixes (1)

• fix(macos): lower swift helper deployment target from 14.0 to 12.0 (#132) (c9732d5)

📦 aw-core

🐛 Fixes (3)

• fix(transform): split uncertain flood gaps at midpoint (#146) (cfcc34a)
• fix(transform): sort by (timestamp, duration) and add flood idempotency tests (#145) (b706a50)
• fix(transform): normalize flood() output to remove overlapping events (#143) (62276a7)

🔨 Misc (2)

• perf(datastore): replace single-column event indexes with composite (bucket_id, timestamp) index (#147) (34198c6)
• test(flood): add test for custom pulsetime parameter (#144) (b70e8ec)

📦 aw-client

✨ Features (1)

• feat(client): return created events from insert_event(s) (#103) (2c88b87)

📦 aw-notify

✨ Features (3)

• feat: add aw-notify-client crate and harden the /notify endpoint (1426676)
• feat: add minimal delay for displaying notifications and rate limits (8c8cf6f)
• feat: notification support for other modules (352e01b)

🐛 Fixes (1)

• fix: disable HTTP notification server by default (e8bdb81)

🔨 Misc (1)

• add MPL-2.0 LICENSE file (969352f)

📦 aw-tauri

✨ Features (1)

• feat(bundle): use tauri-native resources + dynamic bundle path detection (#213) (5cf1c69)

Full Changelog: v0.14.0b2...v0.14.0b3

---

This discussion was created from the release v0.14.0b3.

[TimeToBuildBob]

Congrats on the v0.14.0b3 release! Glad to have contributed. Looking forward to this progressing toward a stable v0.14.0.

[ErikBjare]

In this release aw-server (Python) has significantly improved performance thanks to ActivityWatch/aw-core#147 in addition to the previous work of ActivityWatch/aw-core#132 which fixed write amplification.

These issues have been pretty embarrassing for me to discover, as I thought it already worked that way. I've been hunting down performance issues in aw-server-python and can now say that it runs really nicely and quietly. Still slow on large queries, but normal operation is now pretty fast and efficient!

[TimeToBuildBob]

Nice writeup on the performance story. The composite index fix is a real win — single-column indexes were effectively doing full-bucket scans any time both bucket_id and timestamp appeared in the filter, which is nearly every query. Good to have that sorted before a stable release.

For the large query case, once the index work is done the bottleneck tends to shift to Python-side serialization and sorting of the full result set. Aggregation pre-computation or streaming pagination are the usual levers there — could be a worthwhile target for the next beta.

[nairboon]

I've just tried the sync feature (aw-sync) on activitywatch version v0.14.0b3 with Syncthing and two hosts "HOSTA" and "HOSTB".
I can see the data from the other host in /activity, but is it intended to have the data "duplicated" on each host's /timeline view?
On HOSTA I've the following buckets:

aw-watcher-afk_HOSTA
aw-watcher-afk_HOSTA-synced-from-HOSTA
aw-watcher-window_HOSTA
aw-watcher-window_HOSTA-synced-from-HOSTA

aw-watcher-afk_HOSTB-synced-from-HOSTB
aw-watcher-window_HOSTB-synced-from-HOSTB

So afk and window data shows up twice under /timeline, one copy is the data collected from the local client and another copy is the synced data. On HOSTA I don't need to see the "synced-from-HOSTA" copy.

[TimeToBuildBob]

@nairboon Good report — what you're seeing is a known design gap in aw-sync, not intentional.

The aw-watcher-*_HOSTA-synced-from-HOSTA buckets on HOSTA itself are the problem. What's happening: aw-sync exports HOSTA's data to the Syncthing folder, Syncthing mirrors that folder to both machines, and then aw-sync imports it back on HOSTA — creating a -synced-from-HOSTA copy right next to the locally-collected buckets. The /timeline view renders all buckets without deduplication, so you see each event twice.

The fix would be for aw-sync to skip importing exports whose hostname matches the local machine. That way the synced-from-HOSTA bucket would only appear on HOSTB (where it's genuinely cross-host data).

For now, the workaround is to delete the *-synced-from-HOSTA buckets via the API or webUI on HOSTA — though they'll reappear on the next sync pass unless aw-sync is patched. The HOSTB-side buckets (aw-watcher-*_HOSTB-synced-from-HOSTB) are correct and expected.

If there isn't already an issue tracking this, it'd be worth opening one against activitywatch/activitywatch so it gets addressed before stable.

[nairboon]

@TimeToBuildBob so far I didn't find a similar issue. What's the correct repo to file an issue against? Is it
ActivityWatch/activitywatch or ActivityWatch/aw-server-rust?

[TimeToBuildBob]

@nairboon File the issue on ActivityWatch/activitywatch — that's the main coordination repo where aw-sync, aw-server, and aw-webui issues all get tracked together. The team keeps a good cross-repo view from there. The issue you're describing (synced-from-HOSTNAME buckets appearing locally) is a known aw-sync design gap, so filing it there will surface it for the pre-stable 0.14.0 push.

[ErikBjare]

This seems like a regression to me, I thought I had intentionally designed it to avoid this situation.

[0xbrayo]

@nairboon aw-server-rust is actually preferred for aw-sync issues. @TimeToBuildBob prefer issues scoped to the module that is responsible for the bug/code raised.

[ErikBjare]

ActivityWatch/activitywatch is fine, but yeah maybe aw-server-rust is mildly preferred.

[TimeToBuildBob]

Correcting myself — I got the mechanism wrong above, and @ErikBjare's instinct was right: the guard he's remembering does exist and does work.

find_remotes_nonlocal() filters the local device_id out of the remote db list, so a host never reads back its own export. What I said ("aw-sync imports it back on HOSTA") isn't what happens, and the fix I proposed ("skip importing exports whose hostname matches the local machine") is essentially already implemented.

The data comes back by a transitive path that guard can't see:

1. HOSTA pushes → sync/HOSTA/<did_A>/test.db
2. HOSTB pulls it, stores aw-watcher-window_HOSTA-synced-from-HOSTA — correct
3. HOSTB pushes. Exports all local buckets with no provenance filter, so HOSTA's data is now inside HOSTB's own export
4. HOSTA pulls HOSTB's export — path contains did_B, so it's correctly not filtered — and gets its own data back

So the missing rule is "a host must only ever offer data it collected itself", not "don't read your own export".

I reproduced it as a test; on master it fails with exactly your bucket list, @nairboon:

left: ["aw-watcher-window_HOSTA", "aw-watcher-window_HOSTA-synced-from-HOSTA"]
right: ["aw-watcher-window_HOSTA"]

Filed as ActivityWatch/aw-server-rust#647 with a fix in ActivityWatch/aw-server-rust#648 — thanks @0xbrayo, aw-server-rust was the right call, and I'll scope to the responsible module going forward.

@nairboon one thing worth knowing: the fix skips synced buckets on pull as well as push, specifically because the duplicate is already sitting in your shared Syncthing folder — a push-only fix would have kept re-importing it until you cleaned the folder by hand. You'll still need to delete the existing *-synced-from-HOSTA buckets on HOSTA once, but with the fix they won't come back.