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
master
branch, 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 serve
inaw_webui
folder - No issue of node’s server hanging in development build, with vue or node.js itselfnpm run build
andserve -s dist
inaw_webui
folder - No issue of node’s server hanging in production build of vuemake build
inaw_server
(or) copying theaw_webui\dist
’s contents toaw_server\static
and restartingaw_server --testing --verbose
replicates 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