New modules fail to start at launch

[Terrance]

I've just installed the 0.13.1 AppImage release, which includes aw-sync but does not enable it by default.

aw-qt's config updated to load it:

[aw-qt]
autostart_modules = ["aw-server", "aw-sync", "aw-watcher-afk", "aw-watcher-window"]

But when starting aw-qt I get the following:

[2024-07-01 23:10:16][INFO][aw_sync]: Starting daemon...
[2024-07-01 23:10:16][INFO][aw_sync]: Pulling from all hosts
[2024-07-01 23:10:16][INFO][aw_sync::util]: Found remotes: ["hostname"]

The log ends there. Pressing Restart seems to result in the module loading successfully. Enabling the module from the tray icon menu without updating autostart_modules also seems to start it without any problems.

The same happens trying to load aw-watcher-input, which also isn't enabled by default.

[Terrance]

Similarly on Windows (0.13.1 installed via Chocolatey), having configured those two additional modules to run at startup, they just don't -- no log files and no startup error, but no data from them and they're not ticked in the tray menu.

Trying to enable them from that menu logs a warning that it's trying to stop them but they're not currently, so there seems to be some mishandled state here (maybe related to #103).

[galvanized]

Having the same issue. Manually enabled aw-sync in aw-qt config, get warning popup, no logs (or even a log directory). On Windows 10, 0.13.1 installed via installer. However, I've also had issues starting it from the tray menu.

[ErikBjare]

Try running aw-sync directly from a terminal and see what the output is.

[Terrance]

Having just attempted to start it early on boot, I got the following:

$ aw-sync
[2024-08-29 13:00:52][INFO][aw_sync]: Starting daemon...
[2024-08-29 13:00:52][INFO][aw_sync]: Pulling from all hosts
[2024-08-29 13:00:52][INFO][aw_sync::util]: Found remotes: ["hostname"]
Error: "Local server http://127.0.0.1:5600/ not running"

Note that the output ends at the same point, but trailed by what appears to be an error not via the logging framework to say the core service isn't running. Probably these new modules depend on the core being up at their startup, but it's not ready yet? It would also be useful to have that error captured by aw-qt.

[Terrance]

This is still happening in 0.13.2 -- any updates?

[ErikBjare]

Ah, looks like a race condition where the new modules are assuming the server to already be running and not waiting for it to start.

I've started seeing the same on my system, will fix.

Note that the output ends at the same point, but trailed by what appears to be an error not via the logging framework to say the core service isn't running. [...] It would also be useful to have that error captured by aw-qt.

Yes we're not great at this. We try to make sure such messages end up in the log (which is being read rather than capturing stderr/stdout), but some messages just never get logged to file (such as this critical error in aw-sync).

[ErikBjare]

Implemented client.wait_for_start() with exponential backoff instead of relying on heuristics like sleep(1):

• https://github.com/ActivityWatch/aw-client/pull/87
• https://github.com/ActivityWatch/aw-server-rust/pull/495

Now used in aw-sync, and all watchers + aw-notify:

• https://github.com/ActivityWatch/aw-watcher-afk/commit/9f9a4fd3c51635ba362a51ac8e7bc47abd56fa05
• https://github.com/ActivityWatch/aw-watcher-window/commit/c80aa5adbbe5959fcb661148aeb9f3898e6b68f3
• https://github.com/ActivityWatch/aw-watcher-input/commit/9bb5045456524b215ae11f422b80ec728c93bac7
• https://github.com/ActivityWatch/aw-notify/commit/c5f31068a470e65c23399f7e60995bcf453c0bc8

Thanks for reporting!

[Terrance]

As far as I can tell, this hasn't made it into a release yet (the last one being from 5th October, just before the fix) -- is a new desktop release due soon?