Description
Since optd is built on top of the asynchronous runtime tokio, traditional debugging (with print statements or gdb for example) is quite difficult. What most async Rust projects use instead is logging and tracing, specifically the tracing library.
As a TLDR; tracing gives you the ability to instrument your code at compile-time to collect structured event logs. optd is a prime target for tracing and kills 2 birds with 1 stone: we want the ability to debug optd while we develop it, and we also want to be able to explain what is happening during optimization. tracing's system of Spans will make this super convenient, and there are a lot of really interesting things that could be done with tracing (for example, custom Subscribers that could tell us everything from what rules were applied to how deep the optimization trees get).
To whoever picks up this task, I strongly recommend both watching this entire livestream called "Decrusting the tracing crate" which breaks down how tracing works and a bit of how to use it, as well as reading through a majority of the documentation.
Note that adding detailed logs makes the debugging process of async Rust incredibly simple once you understand how to filter and enable different levels and spans of events. Once things have been pieced together, this should be a priority (as well as a great onboarding project).