tokio::spawn silent failure in tauri?

[bburdette]

My program started as a web server, which is now in a library and gets linked in to a tauri app.

I'm added a (3rd party) job manager crate to the library and that job manager uses tokio::spawn to kick off new tasks. In the actix-web server it works.

But in tauri it seems something goes wrong; the job manager posts a message ("Starting job") from just before the tokio::spawn point, but no messages are ever sent from inside the task itself. So it seems that tokio::spawn is silently failing.

I've tried making the tokio handler async and not. No difference.

I'm not really too up on tokio failure modes. Why would tokio::spawn quietly not work from inside a tauri handler? What should I look for?

[bburdette]

Turns out the spawn was taking place in a function that, in turn was called by another function from an actix_rt context. That's because actix_rt allows !Send futures, and the web server functions I'm reusing in tauri are !Send. However, the actix_rt context is single threaded which doesn't work well with the job manager, at least sometimes?

Still not sure why the job manager works in the web server which also uses actix_rt, but it does.

What's wild is that in tauri, putting a 100ms sleep after the tokio::spawn() makes it work fine.

[alexiokay]

thanks!! I added sleep and it finally works :D I spent 6 hours trying to fix it...

[bburdette]

wow interesting. you know what I ended up doing was going back to a non-async handler, and spawning jobs from that. then I don't need the random and weird sleep() call. the job manager author added support for actix-rt though, so I might go back and try that again when I get a chance.

[alexiokay]

I was trying to run mdns process to advertise my websocket server, I dont remember which library it was but I had the problem with all libraries I tried. My nuxt app was crashing all the time.

I don't really remember if I tried to run it as non async, but I spent so much time doing different combinations xD The same script worked outside of tauri and I have no idea why it happens only in tauri

[peabnuts123]

I have also encountered this. I didn't manage to solve it. I ended up just making enough refactors that I didn't need to run a nested spawn() any more. Definitely something peculiar going on. Even when using tauri::async_runtime::spawn(). I don't have a reproduction on-hand but the structure was basically something like this:

async tauri::command => spawn(some background task) => spawn(regularly-occurring background task)

and it was regularly-occurring background task that wouldn't run. Adding a sleep().await to some background task did help the nested spawn run, but the sleep had to be long enough to let regularly-occurring background task run, making the spawn() somewhat moot (as it basically had to block the calling context).

[alexiokay]

Hmm. I don't know exactly why, but after I all my functionalities into tauri setup() function to get access to app_handle + I run my task in tauri::async_runtime::spawn rather than Builder::new_multi_thread.spawn the problem is gone and sleep is not needed anymore