fix(cli): prevent spinner from appearing in error messages

[michael-johnston]

Before this PR CLI errors were printed while the Rich Status spinner was still live, so there were written onto the same terminal line.

For example
ado describe experiment started Status("Initializing Actuator Registry") and then looked up the experiment inside that context. For a missing experiment such as solve_mip, _ado_lookup_cli_experiment prints:

ERROR: Experiment solve_mip does not exist

via a separate Rich Console on stderr. That bypasses Live’s stdout/stderr interception. The spinner is an in-place \r line, so the error is appended to it:

⠋ Initializing Actuator RegistryERROR:  Experiment solve_mip does not exist

Fix proposed and implemented here is to initialize the actuator registry under the spinner, then stop it before lookup and error printing.

The same lookup-while-spinner-is-live pattern is also fixed in ado get experiment and ado template space --from-experiment.

[michael-johnston]

This may introduce additional newlines in SUCCESS situation - checking.

[AlessandroPomponio]

Most of the times in these situations I believe i pass the spinner down to the function that handles the errors and i make that function stop it when needed

[michael-johnston]

Most of the times in these situations I believe i pass the spinner down to the function that handles the errors and i make that function stop it when needed

Can you point to an instance of this pattern?

[AlessandroPomponio]

ado/ado/cli/utils/resources/formatters.py

Line 237 in fe34757

def format_ado_get_stats_for_operations(

[michael-johnston]

I believe i pass the spinner down to the function that handles the errors and i make that function stop it when needed

I can't find anywhere where that function calls stop on the spinner when there is an error??

The existing pattern seems to be local to command handlers, e.g. ado/cli/resources/actuator/get.py

[michael-johnston]

@AlessandroPomponio see above comment

[AlessandroPomponio]

It seems like I'm passing down the spinner/status objects to update them more than to stop them, but I think the same applies

[michael-johnston]

So just to be clear here the error printing code in question is in _ado_lookup_cli_experiment

It's used in three of the four places the problem being addressed occurs. This doesn't take a rich status as arg.

The problem arises because the call to this function is inside a with Status: block.

The solution implemented is just to move _ado_lookup_cli_experiment out of the spinner context - because it's cheap and doesn't really need to be in spinner.

What you are proposing is to add a status parameter to _ado_lookup_cli_experiment and pass the spinner in. And update the error printing code in _ado_lookup_cli_experiment to handle stopping the spinner.

Is this correct and if so is it really necessary? Because it seems like a new pattern different to making a long running function rich Status aware (for updates) - instead making a short running function status aware in to handle error printing if it happens to be in a rich context.