[Cli] Add default_prompt_response option to set_global_config command

[fgrust]

[WIP]

Description

Updates for issue #2205

Test Plan

This PR is in WIP, so far saving the configuration in the config file works well.

$ aptos config set-global-config --default-prompt_response yes
$ aptos config show-global-config
{
  "Result": {
    "config_type": "Global",
    "default_prompt_response": "Yes"
  }
}

---

This change is 

[gregnazario]

Hey this is a great first start!

I think you'll want to do one of these two options:

1. Make an enum with, [yes, no, prompt], where prompt is default
2. Take advantage of Option<bool>, to handle None as prompt.

It's probably easier from a readability perspective for the first one, and then it can default to prompt.

Then you can loop this into the PromptOptions to read the global config and use this as the default behavior rather than what it does right now

[banool]

Agree with Greg, particularly with the first thing he suggests.

[fgrust]

Hey this is a great first start!

I think you'll want to do one of these two options:

1. Make an enum with, [yes, no, prompt], where prompt is default
2. Take advantage of Option<bool>, to handle None as prompt.

It's probably easier from a readability perspective for the first one, and then it can default to prompt.

Then you can loop this into the PromptOptions to read the global config and use this as the default behavior rather than what it does right now

I also agree with the first thing.

Please review the updated code, and then I will move forward with PromptOptions as the config logic is approved.

[banool]

Will look next week :)

[banool]

Can we use serde(default) here instead of making this an Option? As it is now the Option doesn't really make much sense given there is also a Prompt variant of the PromptReponseType enum.

[fgrust]

In that case, it would save default_prompt_response: Prompt in the config file, even if we run set-global-config without --default-prompt-response option. It's what we should come up with?

[banool]

It could also be prompt right?

[banool]

Awesome work, this looks like it is good to go to me! My only concern now is if this PR lands, users might think the feature is ready, but it doesn't actually affect anything yet. Could you perhaps stack then next PR on top of this one and then we'll land them all together?

[fgrust]

Awesome work, this looks like it is good to go to me! My only concern now is if this PR lands, users might think the feature is ready, but it doesn't actually affect anything yet. Could you perhaps stack then next PR on top of this one and then we'll land them all together?

Sure thing!. I am doing the exact implementation. thanks.

[fgrust]

I thought prompt_yes_with_override function in common/utils.rs is good place to overwrite prompt_options parameter and run. do you have the better idea? this line

[banool]

A couple of points here:

First, GlobalConfig only reads the config at the global folder (e.g. ~/.aptos), we want to read the correct config based on scope. So if there is an .aptos dir in the current dir, use that. You want something like this instead:

let config = CliConfig::load(ConfigSearchMode::CurrentDirAndParents)?;

Second, we shouldn't load the config here, it should be passed in, since in some cases we might already have it. That way we avoid unnecessary double reads of the config.

[fgrust]

First - As default_prompt_response is saved in global config file, I think using GlobalConfig::load rather makes sense. CliConfig::load loads the profiles only. Otherwise, it should be stored in the profiles as needed.
Second - I agree with your principle. GlobalConfig::load is used to get .aptos folder path mostly to load profiles, save them, and check the config existence and called more than once to load and then save in a line. Furthermore, it's not designed to pass the global config from the root to the leaf, which means it should be redesigned and/or needed much updates relatively.

@banool, thoughts?

[banool]

First: Okay I may be misunderstanding the code, I'd have to dive deeper. Though for now I'll invoke @gregnazario to comment since he knows the CLI better than anyone 😛

Second: Same thing, what do you think @gregnazario? I see instances where we have a config already, it seems redundant to load it again. Perhaps the config object should be smarter and act as a passthrough cache.

[gregnazario]

Sorry for the delay, been very very busy.

I would put it in the global config like he does here, and I think it's the right choice.

This code maybe should read a slightly different way. This will let you override via CLI flags default behavior even if you sent it, allow you to set a default which overtakes so you don't need to send flags, and allow for default prompting otherwise.

This pseudocode below I think lets it be very simple and straightforward for someone to read afterwards and tell what's going on.

// Handle CLI flags
If assume_no:
 return abort
else if assume_yes:
 return Ok

// Then handle default or prompt behavior
bool is_yes = if let Some(response) = default_response:
  response
else:
  prompt and get response

if is_yes:
  return Ok
else:
  return abort

I see now you have Prompt as an option, then replace the end there with a match statement

[fgrust]

thanks for the reply. I just did some changes. could you please review again?

[github-actions]

✅ Forge suite land_blocking success on f1a570fa1109dcebdc096b0e29a7c8c539fda56c

performance benchmark with full nodes : 6819 TPS, 5816 ms latency, 9700 ms p99 latency,no expired txns
Test Ok

• Grafana dashboard
• Humio Logs
• Test runner output
• Test run is land-blocking

[github-actions]

✅ Forge suite compat success on testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> f1a570fa1109dcebdc096b0e29a7c8c539fda56c

Compatibility test results for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> f1a570fa1109dcebdc096b0e29a7c8c539fda56c (PR)
1. Check liveness of validators at old version: testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b
compatibility::simple-validator-upgrade::liveness-check : 7144 TPS, 5406 ms latency, 7100 ms p99 latency,no expired txns
2. Upgrading first Validator to new version: f1a570fa1109dcebdc096b0e29a7c8c539fda56c
compatibility::simple-validator-upgrade::single-validator-upgrade : 4826 TPS, 8246 ms latency, 10700 ms p99 latency,no expired txns
3. Upgrading rest of first batch to new version: f1a570fa1109dcebdc096b0e29a7c8c539fda56c
compatibility::simple-validator-upgrade::half-validator-upgrade : 4828 TPS, 8258 ms latency, 10900 ms p99 latency,no expired txns
4. upgrading second batch to new version: f1a570fa1109dcebdc096b0e29a7c8c539fda56c
compatibility::simple-validator-upgrade::rest-validator-upgrade : 6799 TPS, 5650 ms latency, 10000 ms p99 latency,no expired txns
5. check swarm health
Compatibility test for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> f1a570fa1109dcebdc096b0e29a7c8c539fda56c passed
Test Ok

• Grafana dashboard
• Humio Logs
• Test runner output
• Test run is land-blocking