Recommended pattern for spawning many listeners

[Kinrany]

What's a good way to do error/panic handling and cleanup when spawning many tasks that subscribe to various subjects or stream consumers?

tokio::spawn ignores panics if the JoinHandle is dropped. JoinSet + restarting all subscription on error/panic works I think, but feels too heavy-handed. Writing a custom spawning function feels wrong, I can't believe there isn't a better way to do it.

This isn't really a NATS-only question per se, but having a solution to this problem is particularly important for code that relies on NATS.

[Jarema]

Hey.

It sounds like a general async rust question rather than nats.

If you want to get errors from JoinHandle just don't drop it and handle it.

Not sure why you would need to restart all subsriptions on error. Can you elaborate?

If you decide to panic in your app - you probably have a reason to do it (unrecoverable error that should crash the app). Not sure why you would like to recover other way than by restaring the app. If you do not want to crash, error instread of panic.

You can also communicate across tasks via channels, like mpsc or oneshot. Also, in many cases, maybe you do not need a separate tasks, but polled futures instead.

I would love to help, but I'm not sure how.
Maybe if you shared a snippet of code we could take a look and see if we can help.

[Kinrany]

A common mistake that is present in https://natsbyexample.com/examples/services/intro/rust as well is spawning several tasks in parallel and never using the JoinHandles. It means that the app will continue to run even if some parts of it broke silently.

The question then is, how does one handle them?

You're right that restarting is at best a convenience and not really important here. The real problem to solve is polling a bunch of tasks/futures until one of them fails. Which is indeed a general async question, but one that is easy to never run into but totally unavoidable when using NATS.

And again, JoinSet solves this. But it doesn't feel elegant.

[Jarema]

Nats by example omits on purpose code that can make understanding each use case harder by cluterring it.

Not handling tasks in production app is simply a programmer mistake.

You have also other options:

• you can run select against few Streams
• you can join streams
• communicate over mpsc

There are really many ways to do that in Rust. Depending on scenario, probably some are bettet than other.