bug(rust): CLI argument parser doesn't work for some configurations.

[josedev-union]

The following configurations are not parsed from either env var or cli args.
Configurations whose key includes multiple words are not parsed from CLI args correctly. Here are typical ones.(edited)

chains.<chain_name>.addresses.interchainGasPaymaster
chains.<chain_name>.addresses.validatorAnnounce

Btw, when I use a config file, it works.
Here is a discord link for more details https://discord.com/channels/935678348330434570/984123861144600587/1139906822510219284

[josedev-union]

I think i found the reason.
In the CommandLineArguments, the key is converted to lowercase but RawCoreContractAddresses uses camelCase serde. i.e. RawCoreContractAddresses.interchain_gas_paymaster is seralized to interchainGasPaymaster and vice versa.
On the other side, the cli argument --chains.<chain_name>.addresses.interchainGasPaymaster is parsed as chains.<chain_name>.addresses.interchaingaspaymaster and it doesn't match with the camelCased result.

hyperlane-monorepo/rust/hyperlane-base/src/settings/chains.rs

Lines 89 to 95 in d88fd4c

	#[derive(Debug, Deserialize)]
	#[serde(rename_all = "camelCase")]
	struct RawCoreContractAddresses {
	mailbox: Option<String>,
	interchain_gas_paymaster: Option<String>,
	validator_announce: Option<String>,
	}

hyperlane-monorepo/rust/hyperlane-base/src/settings/loader/arguments.rs

Line 80 in d88fd4c

let mut key = key.to_lowercase();

So this issue is not only affecting to chains.x.addresses but also all the other configurations which include multiple words in the key. For example, chains.${CHAIN_NAME}.finalityBlocks.

[josedev-union]

I can reproduce this issue with the following code snippet

use serde_json;


#[derive(Debug, Deserialize)]
#[serde(rename_all = "camelCase")]
struct TestHyperlaneArgParse {
    single: Option<String>,
    camel_case_upper: Option<String>,
    camel_case_lower: Option<String>,
    snake_case_upper: Option<String>,
    snake_case_lower: Option<String>,
}

fn main() {
    let json_data = r#"
        {
            "single": "single",
            "camelCaseUpper": "camel_case_upper",
            "camelcaselower": "camel_case_lower",
            "snake_Case_Upper": "snake_case_upper",
            "snake_case_lower": "snake_case_lower"
        }
    "#;

    let deserialized: Result<TestHyperlaneArgParse, serde_json::Error> = serde_json::from_str(json_data);
    match deserialized {
        Ok(data) => {
            println!("{:?}", data);
        },
        Err(err) => {
            println!("Error: {:?}", err);
        }
    }
}

Its output is

TestHyperlaneArgParse { single: Some("single"), camel_case_upper: Some("camel_case_upper"), camel_case_lower: None, snake_case_upper: None, snake_case_lower: None }

[mattiekat]

Can you elaborate on what "Not parsed correctly means". The argument parser was intentionally designed to lowercase the strings to be insensitive to either the literal originchainname or originChainName or OriginChainName and so on. The JSON config parser is more rigid as it has a better definition of what is expected, and the ENV parser is, well, env format unfortunately and that is why it is SCREAMING_SNAKE_CASE.

[mattiekat]

Wait, okay, I see, the issue is that you are not able to specify the core contract address via arg due to casing issues. I think this reasonably slipped through testing because to the best of my knowledge we have always specified this via config file.

[josedev-union]

Wait, okay, I see, the issue is that you are not able to specify the core contract address via arg due to casing issues. I think this reasonably slipped through testing because to the best of my knowledge we have always specified this via config file.

yes, the problem is that the parser does lower-case while obj deserializer uses camelCase.
I see. Config files work as expected but we deploy all agents on K8s clusters by using the helm chart in this repo. And that helm chart only relys on env vars.
I found this issue for env vars first, and after some troubleshotting, found that cli args don't work either.

[mattiekat]

As a stop gap I recommend creating a config file using your helm chart. What we do internally is we ship the docker image with the chains config you see in the repo; this means our helm files don't need to generate the config file.

[mattiekat]

This bug might block the planned changes in #2215

[josedev-union]

As a stop gap I recommend creating a config file using your helm chart. What we do internally is we ship the docker image with the chains config you see in the repo; this means our helm files don't need to generate the config file.

yeap, thanks for your suggestion