Just tried this out in one of my projects, here's what happened:
do something works without a problem.
do something else never goes off.
the rest of the game keeps running as normal. You can even call foo() again any number of times and do something will still go off.
Having it waiting in the background didn't seem to have much of a performance impact. I started 5000+ of them and foo() only took up ~0.6% frametime with the rest of my game running alongside it.
Thanks so much for testing that out! That's very informative and even more thorough than what I was looking for! I wasn't at my computer when I posted this so I couldn't test it myself.
I ended up connecting the signal to a secondary function to run on finished to avoid any potential memory errors, but it's super helpful to know that the performance impact is minimal.
On their own, there's usually no timeout condition for async functions like this. The task (I don't know what they're called in gdscript, I use c#) will just hang until it completes, errors, or is canceled.
There are cases when you can run into timeouts, such as sending web requests. There are also use cases for making your own timeout trigger. In both of these cases, the timeout is because of what made the task, not something inherent in tasks.
Thanks for the explanation! Your explanation led me down a rabbit hole of seeing if there's a way to cancel an await call, from what I can tell there was no clear way to do so. In my case I ended up connecting the signal to a secondary function instead of utilizing the await command, I'm not entirely sure if there's an advantage to utilizing one method over the other.