ERR_CONNECTION_REFUSED on autorun

[dvlpr91]

Hello!

I have set the tauri app to run automatically when windows OS boots up.

However, when the tauri app is automatically launched after Windows boots, I get an ERR_CONNECTION_REFUSED error page. (It must be done by re-launching the tauri app.).

It seems that the tauri app is trying to load the page after booting, but before running the local web server.

Is my rust code the problem? (Plugins load order)

#![allow(unused_imports)]
use tauri::{AppHandle, Manager};

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    let mut builder = tauri::Builder::default();

    #[cfg(desktop)]
    {
        builder = builder.plugin(tauri_plugin_single_instance::init(|app, _args, _cwd| {
            let window = app.get_webview_window("main").expect("failed to get window");

            window.show().expect("failed to show window");

            window.set_focus().expect("failed to set focus");
        }));
    }

    builder
        .plugin(tauri_plugin_autostart::init(
            tauri_plugin_autostart::MacosLauncher::LaunchAgent,
            None,
        ))
        .plugin(tauri_plugin_notification::init())
        .plugin(tauri_plugin_process::init())
        .plugin(tauri_plugin_shell::init())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

But I'm using svelte, and it's a static adapter, so I don't think I need a server... Why does tauri run a local server...

[FabianLars]

This sounds like the tauri dev instance is registered as the autorun entry. This one does need your svelte dev server. Maybe put the autostart registration behind #[cfg(dev)] to prevent this.

[dvlpr91]

Thank you very much for your valuable reply.

However, I did not understand the meaning of put the autostart registration behind #[cfg(dev)] to prevent this.

...
  builder
    .plugin(tauri_plugin_autostart::init(
      tauri_plugin_autostart::MacosLauncher::LaunchAgent,
      None,
  ))
...

If you are talking about the above part, I think this is just the part that connects the plugin.

Please understand my limited understanding of the RUST language.

[FabianLars]

you're right, that part should only start the plugin, not register your app in the os autostart list.

still, the idea still applies, if you register the entry in js then you could use tauri's isDev function (or just check the current url).

if you want to check if my assumption about the issue is actually correct you can check Task Manager -> Autostart -> Right click on your app -> Open file path
(On latest windows versions you can also go to Settings -> Autostart -> click on the arrow on the right side of your app)
If the path ends with something like target/debug/ then my assumption was likely correct and you registered a dev instance (unless you tried a tauri build --debug app).

[dvlpr91]

Thank you for your continued interest.

The location of the app that automatically starts on Windows boot is correct.

Again, the error occurs because it is trying to load the page before the local server is up and running. (There is no server for the API, but it appears to be accessing localhost to load the page).

This is my repository.

https://github.com/dvlpr91/bye

[FabianLars]

your app works fine on my system. just to triple check, can you share the registered path?

in a tauri build app there's indead no localhost server so the error doesn't make much sense if it's a prod app.

[dvlpr91]

The image above is what my PC looked like when I first booted it up this morning.

In the image above, you can see that the message localhost has refused the connection.
(It appears that not loading a static file, but rather calling the page through localhost, i.e., the web server.)

My Tauri app is registered in the Windows startup apps.

The startup location is C:\Users\myname\AppData\Local\빠이 and the target is C:\Users\myname\AppData\Local\빠이\빠이.exe.

After building the app, the path to the installation file was as follows app\src-tauri\target\release\bundle\nsis\빠이_1.1.1_x64-setup.exe

Build command: bun run tauri build
(I use the LTS version of the software, including node.js.)

As you may recall, after exiting the Tauri app, you can restart it and it will run normally as follows.

[FabianLars]

thanks for the detailed writeup.

can you also share the output of the tauri info command? I'd like to compare versions, especially the webview2 version.

what's also weird is the console window, that should only show up for tauri dev and tauri build --debug builds...

lastly, can you open the devtools window on the broken app and check the full url it tries to load?

[dvlpr91]

Forgive me for my foolishness.

All in all, your guess was correct.

I don't know if the dev and prod apps share the same storage, but as it turns out, both apps have the status of Registered as startup app.

However, it was the dev app that was running when Windows booted, not the prod app.

Foolishly, I didn't check in Windows' startup apps menu, but just looked at the startup path of the prod app and assumed that this was correct.

I was an idiot who never imagined this simple cause and didn't check it correctly when you suggested a solution.

Your continued attention and solution is greatly appreciated.

Thank you, thank you, thank you, thank you, thank you, thank you!