Pins cpu usage at 100%

[ym1234]

As shown here:
image

Seems like there is a weird interaction between aw-watcher-window and the rust server, because if I turn that off the cpu usage returns to normal.

Info:
aw-server 0.12.2
aw-server-window ????
distro: arch, x11
Python 3.11.3 (I don't think this related)
Linux 6.3.8-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC

[ErikBjare]

What do the logs say?

[ym1234]

Nothing

[2023-06-17 20:26:37][�[32mINFO�[0m][aw_server]: Using DB at path "/home/ym/.local/share/activitywatch/aw-server-rust/sqlite.db"
[2023-06-17 20:26:37][�[32mINFO�[0m][aw_server]: Cannot find assets "./aw-webui/dist/"
[2023-06-17 20:26:37][�[32mINFO�[0m][aw_server]: Using aw-webui assets at path "/opt/activitywatch/aw-server-rust/./static/"
[2023-06-17 20:26:37][�[32mINFO�[0m][aw_server::endpoints]: Starting aw-server-rust at 127.0.0.1:5600
[2023-06-17 20:27:49][�[33mWARN�[0m][rocket::server]: Received SIGINT. Requesting shutdown.
[2023-06-17 20:27:49][�[32mINFO�[0m][aw_datastore::worker]: DB worker quitting

2023-06-17 20:27:07 [INFO ]: aw-watcher-window started  (aw_watcher_window.main:62)
2023-06-17 20:27:08 [INFO ]: Connection to aw-server established by aw-watcher-window  (aw_client.client:436)
2023-06-17 20:27:43 [ERROR]: Unhandled exception  (root:52)
Traceback (most recent call last):
  File "aw_watcher_window/__main__.py", line 4, in <module>
  File "aw_watcher_window/main.py", line 89, in main
  File "aw_watcher_window/main.py", line 144, in heartbeat_loop
KeyboardInterrupt

[ErikBjare]

Can you reliably reproduce? Try running with verbose logging.

[ym1234]

Found the problem, for some reason I had ~70mb persistqueue files for both the window and afk watchers,
leading them to hammer the server with requests trying to update the main database which shot the cpu usage to 100% (I assume? I'm not familiar with how aw works). Deleting these files solved the problem.
Maybe there should be something that warns the user when the size of queued operations exceeds some limit?
https://0x0.st/HTu_.png

[TimeToBuildBob]

The root cause was identified by the reporter: ~70MB of accumulated persistqueue files from the window and AFK watchers, causing a burst of queued heartbeats to hammer the server on startup. Deleting the queue files resolved it.

This is a client-side queuing issue rather than a server bug — aw-client's persistqueue can grow unbounded if the server is unreachable for extended periods, then floods requests when connectivity returns.

A potential improvement would be to cap the queue size or add a warning when it exceeds a threshold, but that would be tracked in aw-client (see ActivityWatch/aw-client#7 for related queue management).

This issue can likely be closed as resolved/wontfix — the server behaved correctly, just got overwhelmed by the queued request volume.