activitywatch: Slow UI and timeouts `30000ms` on weekly/multi-day reports

Oh, surprising that it ran off 5666! It should only do that in testing mode (if aw-qt is started with --testing) or if aw-server-rust is built in non-release mode. It should run off 5600, just like aw-server-python.

I’ll look into that. Thanks for the feedback!

I just implemented a ‘request timeout’ setting which lets users set their own max timeout, for large queries and such: https://github.com/ActivityWatch/aw-webui/commit/f75ac9d939b0841723dc00a23a3c575ecc25a5a9

In March I also implemented proper request cancellation (https://github.com/ActivityWatch/aw-client-js/commit/c232696ab0892374124ed576058fe205eba12e21 & https://github.com/ActivityWatch/aw-webui/commit/7e16e03a66b392142c6461624d49827616b40803) which should prevent requests stacking (leading to unresponsiveness).

Since these two things have been fixed and will be in the next release, I’m closing this issue.

Thanks everyone for reporting!

awesome @ErikBjare - thank you so much. So I did would you described - see attached my current config file. However, if I now (re-)start activity watch, I can’t access the webui (waited 20min - still not available). I can only access it, if I also enable the old server module manually. I’m trying to check the logs - would the rust logs also be located in the “aw-server” log folder? cause I don’t see a “aw-server-rust” folder in my “activitywatch\Logs” dir.

About the large reports - I wouldn’t consider mine as large… I usually query one day ( so day per day) of the last week and still very frequently run into 30sec timeouts - on average I’m running more often in these timeouts than not running into them.

Thanks for all your help here - really appreciated it - as said, I love this project 😃

same here 😕 - however, not new here. restarting activity watch for end-of-week-time-booking at least 5-10 times on fridays since months/versions (same on v11; currently running v0.12.0b2). I really love this tool, but the constant restarting is really enoying. Btw. no issues with the tracking at all - if, after some restarts, queries finally don’t run into time-outs, all data is there from the entire week.

I’m also wondering what is the right way to migrate to rust? docs are not very helpful here IMHO (https://docs.activitywatch.net/en/latest/migrating.html#migrating-to-aw-server-rust) Do I need to have booth servers activated so migration starts? why is rust deactivated after restart? Why can’t I reach localhost when only rust-server is activated? I have honestly no idea what steps to take for the migration and what modules need to be enabled in the end and how I can persist activated modules over restarts…plz help 😃

After switching to the rust version it still timeouts on Ubuntu 22.04 with v0.11.0. I also have the localhost:5666 problem.

Btw this is such a useful and cool project, thanks for your work. ❤️

quick thanks to you folks! rust version works perfectly - haven’t had any timeout so far. queries return almost immediately. 🎉 thanks so much for helping me migrate 😃

no data is actually lost, it just takes some effort to consolidate again (which will prob be too difficult for non-programmers)

I guess, but that in essence means that it’s essentially lost for almost all users.

sorry for spamming - but it seems the other modules also don’t know about the :5666 port… cause there’s no data coming in… guess the other modules are trying to send data to :5600… So I found the toml config for the rust-server and changed the default port to 5600. now everything works as expected.

Huh, that’s a bit slower than I’d expect. You could always try switching to aw-server-rust, which is much faster (see https://docs.activitywatch.net/en/latest/migrating.html).

Also, maybe queries to database “stacked”

This is probably true. I don’t think we cancel query requests when they should be.