activitywatch: Clicking on menu options doesn't load any pages
- [ X] I am on the latest ActivityWatch version.
- [ X] I have searched the issues of this repo and believe that this is not a duplicate.
- OS name and version: Windows 10.0.19044
- ActivityWatch version: 0.11.0
Describe the bug
When I click any of the menu options of the dashboard nothing happens. Sometimes even the dashboard doesn’t load at all.
To Reproduce
- Run ActivityTracker
- Click on the icon tray the option Open Dashboard,
- The browser loads (sometimes) on localhost:5600 and it loads the Home content (the one with the Hello early user message
- Clicking on any menu option doesn’t do anything. No errors on the console either.
Expected behavior
Something should load!
Documentation
Additional context
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 3
- Comments: 25 (8 by maintainers)
Commits related to this issue
- [Fix] Re-enable Flask's multi-threading To solve issue: https://github.com/ActivityWatch/activitywatch/issues/773 — committed to ShootingKing-AM/aw-server by ShootingKing-AM 2 years ago
This issue has been already fixed in the
masterbranch, but it hasn’t been released yet.Although, if you are in rush, you can download the nightly build from here: https://github.com/ActivityWatch/activitywatch/actions/runs/3533130809
At the bottom of the page is the Artifacts section, where you can find the build for Windows (
builds-Windows-py3.9) and for other operating systems.I released v0.12.2b1 this week, that should have the bug fixed: https://github.com/ActivityWatch/activitywatch/releases/tag/v0.12.2b1
However, I don’t have a Windows machine available, and we also had a performance improvement change that is untested in the wild: https://github.com/ActivityWatch/aw-watcher-window/pull/83
Please try it and let me know if it works for you! You can use the rocket react on this message to let me know it works.
I am releasing an UNOFFICIAL build for testing here since i think the PR’s gonna take some time and CI seems not building yet. Github only allows 25MB uploads so - activitywatch-v0.12.1.dev-d8c7753 (The one line change done is in the PR - https://github.com/ActivityWatch/aw-server/pull/94)https://github.com/ActivityWatch/activitywatch/issues/773#issuecomment-1370838605
I am also experiencing the same issue. webui does not get some assets sometimes logo, sometimes .js, sometimes .css. It seems the Flask(python) kinda hangs for ~120 secs when its getting excess requests (even normal page loading or going to other tabs(Settings, Timeline, Tools etc…) kindof hangs flask). Flask being a good warrior does not seem crash but processes the requests after ~120secs for me, maybe it has an underlying queue. (idk much about its internals)
Enabling the default multi-threading functionality of Flask seems to solves the issue (like now it never misses a request), which was disabled explicitly by https://github.com/ActivityWatch/aw-server/pull/54. Maybe we need to implement proper multi-threaded handling(mutex locks etc…) of the sqlite datastore instead of restricting the Flask’s threads.
Relevant code:
https://github.com/ActivityWatch/aw-server/blob/1d6d24edd1cef91fb843edc771ee3b7a5e3fc294/aw_server/server.py#L113-L120
Logs:
Do notice the Log timestamps in the below log, browser request was put at 00:01:00 itself, but Flask does not honour all the related requests at once. Also do notice the heartbeats received from aw_window_watcher and their timestamps.This happens randomly sometimes but easily once per 2 minutes(rendering beautiful ActivityWatch completely unusable).
aw_server --testing --verbose LOG
aw_server --testing --verbose | Full File | aw-server_testing_2022-10-06T23-57-55.log
More info:
Tested this by,
npm run serveinaw_webuifolder - No issue of node’s server hanging in development build, with vue or node.js itselfnpm run buildandserve -s distinaw_webuifolder - No issue of node’s server hanging in production build of vuemake buildinaw_server(or) copying theaw_webui\dist’s contents toaw_server\staticand restartingaw_server --testing --verbosereplicates the issue.Therefore the issue only comes when the webui is hosted by Flask itself, combined with the log above, enabling multi-threading should be good for now (https://github.com/ActivityWatch/aw-server/pull/94)
My env:
Versions