Taskvisor 0.2 adds restart policies and async task supervision

Hand-rolling retries in Tokio just got a cleaner alternative. Taskvisor 0.2 added a lightweight supervision layer for async Rust, giving developers restart policies, backoff, and an event bus instead of scattering failure handling across every spawn call.

The crate’s docs.rs description framed Taskvisor as a lightweight task orchestration library that provides primitives to define, supervise, and restart async tasks with configurable policies. It is built as a foundation for higher-level orchestrators and agents, not another application framework, and its SupervisorConfig spells out the parts that matter in real systems: concurrency limits, bus capacity for event delivery, a graceful shutdown period, restart policy, backoff strategy, and task timeout defaults. The Supervisor component orchestrates task actors, event delivery, and graceful shutdown, while the Task trait is used for logging, metrics, and stuck task detection during shutdown.

That makes Taskvisor particularly relevant for the sorts of Rust projects that start small and then become operationally messy. A Discord bot or Matrix bridge can move from a single loop to multiple background tasks that need to restart cleanly after panics or disconnects. A home server service, such as a media indexer or local automation daemon, often needs the same kind of supervision when Wi-Fi drops, a database stalls, or one worker wedges. Background workers and schedulers face the same problem at larger scale, where one failed job should not drag down the rest of the system.

Tokio is already the runtime underneath much of that code. Its docs describe it as an event-driven, non-blocking I/O platform for asynchronous Rust applications, with tools for async tasks, synchronization primitives, channels, timeouts, sleeps, and intervals. Taskvisor does not replace those primitives; it layers policy on top of them. That is the point. Instead of every project inventing its own retry loop, shutdown sequence, and crash recovery path, Taskvisor centralizes those decisions in a supervisor.

The real question is whether it cuts boilerplate enough to matter. For ad hoc spawn-and-retry code, the answer looks like yes, especially once a project needs global limits, event delivery, and explicit restart behavior. Older projects such as task-supervisor and taskvisor 0.0.10 already pointed to demand for keeping Tokio tasks alive with restart and backoff rules, and Taskvisor 0.2 now pushes that idea into a more formal supervision model. For Rust services that have outgrown simple retries, that is a practical shift, not a cosmetic one.