ActivityWatch/aw-server-rust

getting 404 shortly after starting with aw-qt

skewballfox opened this issue · 6 comments

skewballfox commented

Not sure if I should post here or in the main activitywatch repo.
I'm running into an issue where if I run aw-qt, and then migrate to 127.0.0.1 I immediately get a 404 message from rocket.

steps to reproduce

  1. clone activity watch, pull submodules, cd into the top-level repo
  2. create and activate the .venv
  3. run make build
  4. cd to .venv/bin run ./aw-qt
  5. navigate to 127.0.0.1:5600 or local:5600

the output from the process is complaining about a None response:

[2023-03-13 14:35:36][WARN][_]: Response was `None`.
[2023-03-13 14:35:36][WARN][_]: No 404 catcher registered. Using Rocket default.
[2023-03-13 14:35:37][WARN][_]: Response was `None`.
[2023-03-13 14:35:37][WARN][_]: No 404 catcher registered. Using Rocket default.
2023-03-13 14:37:59 [INFO ]: Became AFK  (aw_watcher_afk.afk:97)

it's also worth noting that when I run with cargo run --bin aw-server the webui works as expected.

ErikBjare commented
skewballfox commented

yeah, I just saw where it did, my apologies.

[2023-03-13 14:34:57][INFO][aw_server]: Cannot find assets "./aw-webui/dist/"
[2023-03-13 14:34:57][WARN][aw_server]: Unable to find an aw-webui asset path which exists, falling back to ./aw-webui/dist
[2023-03-13 14:34:57][INFO][aw_server]: Using aw-webui assets at path "./aw-webui/dist/"
[2023-03-13 14:34:57][INFO][aw_server::endpoints]: Starting aw-server-rust at 127.0.0.1:5600
skewballfox commented

I think I realize the problem and might have an idea for a fix, at least for linux.

It needs to be able to find the assets for the webui, which isn't a problem when testing with cargo run, but it is when running the binary from anywhere else. I'd recommend using the $XDG_DATA_HOME which is part of the XDG Base Directory Spec. Normally things relevant to application state goes in ~/.local/share/<application>/

looking to confirm, it seems you already have created a folder for the client and the server in there, so I'd recommend copying the necessary directories for the webui to that location as part of your build process.

skewballfox commented

okay, so this turned out to be user error. I wasn't running make install because the account I'm using doesn't have sudo permissions, and the prefix was being set to /usr/local. changing prefix to $(HOME)/.local/share and running make install did resolve the issue.

after reading through the code I realized you are already checking for $XDG_DATA_DIRS and defaulting to that if it exists. I would recommend adding $HOME/.local/share to the search path created if the variable is unset or path is empty. This directory is also part of the xdg base directory spec as $XDG_DATA_HOME (which if I'm being honest, I wasn't aware of it being a separate variable and have just been prepending to $XDG_DATA_DIRS)

ErikBjare commented

Good to hear you figured it out!

If you make a PR with changes that'd get us in line with the spec I'd gladly take a look at them.

I do think we should handle this better than a generic 404 though. If webui assets can't be found, we should probably return a message stating that specifically.

Not the first time I've seen someone ask for help after strange 404s caused by missing assets.

skewballfox commented

I've been looking around for relevant crates for cross-platform directory handling. The most useful I've found so far have been dirs and directories.

The only thing that this won't cover is the system level directories /usr/share and /usr/local/share (he specified why here), which should be checked (in case aw-server-rust) is installed via a package manager.

I could implement that in a PR(later tonight or tomorrow), but I want to confirm that would be a change you would be interested in first