Meta: Warnings about console HOT 6 OPEN

Initial framework for warnings added to the console crate in #113 and #123. Right now, we can associate warnings with tasks and display them!

However, we only have a single warning that we detect: self-wake percentages over 50%. We should now be able to start designing and implementing additional warnings.

from console.

Yeah, this is a great idea. It would be nice to have some fairly modular way of defining warnings, similar to clippy --- obviously the actual detection of warning conditions is generally complex enough that adding a warning will generally require a non-trivial amount of code, but it would be cool to be able to have stuff like toggling on and off specific warnings etc be taken care of out of the box when adding new ones.

For starters though we should probably just write some purely by hand to figure out what they end up looking like...

from console.

So I originally assumed that lints/warnings would be entirely in the console (nothing in the subscriber). The reasons were:

• I didn't want to do too much computing in-process of the monitored application, so having that run in the console seemed better.
• It seemed like one might want to modify some lint configuration when attaching a console (or web view or whatever). Maybe when you first connect, you realize the poll-time-max warning is too aggressive, so you want to restart the console with a higher maximum.

However, I'm now leaning the other way, that it should happen in the subscriber, and the warnings should just be emitted in protobuf and simply shown in the console. This fits more with the console only showing info, not processing and inventing new info. It also means that the code to determine if tasks are triggering warnings doesn't need to be duplicated in different viewing application (like a web view).

from console.

Now I'm starting to lean back the other way, that the warnings code should be entirely in the console, and not in the subscriber. That'd reduce the amount of work the instrumentation library is causing to the user's process. It also happens to be simpler to to do, since we don't need code in both the subscriber and console to handle them, and a new way to send them over the connection.

from console.

FWIW, I'm personally strongly in favor of doing this work in the UI application. Eventually, if we want to have multiple UIs, I expect we would factor out the core data model part of the console TUI into a crate that could be a dependency of the console TUI, a GUI app, web UI, etc. The code for detecting and generating warnings could be in that crate so that it doesn't have to be reimplemented.

from console.

Some additional things that would be nice to add:

• some kind of short identifier for warnings (either a short string name like "poll_time_percent" and/or a number like [W0001])
• users can turn on or off a list of warnings with a CLI arg (using short identifiers)
• some warnings (like the self-wake percent warning) could have configurable thresholds (the percentage of self-wakes). we could consider providing a way to configure this as well...

from console.