getting 404 shortly after starting with aw-qt

[skewballfox]

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]

Does the log say anything about which asset path is used/found?

…

On Mon, Mar 13, 2023, 20:45 Joshua Ferguson ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#350>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKXDOVHVRGYP7FGMG66D5LW352OLANCNFSM6AAAAAAVZQVXME> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[skewballfox]

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]

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]

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]

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]

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