The home for Hyperlane core contracts, sdk packages, and other infrastructure
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
hyperlane-monorepo/rust/hyperlane-core/tests/chain_config.rs

116 lines
3.9 KiB

Better Agent Configuration Parsing (#2070) ### Description This is a significant change to how we parse user configs. The main goal of this PR is to give a clear path and env key to any errors that are encountered when parsing configuration. In order to accomplish this, I have crated a new trait `FromRawConf` which defines a set of steps to validate and convert individual fields. Also for every major config struct, there is now a `Raw*` variant of it which is used by the `config` library to reduce errors that occur during deserialization itself. `Raw*` types should always use the most basic form of a value, such as `String`, `StrOrInt`, `bool`, and ideally optional in all cases. Missing values should be handled during the raw conversion and not by `config`. I also needed to make changes to a number of types stored in the parsed config types to force validation forward to the parsing step instead of doing it when we read the config value. This also required me to create a filter to prevent trying to validate certain configs that we would not ever need to load. These changes can also be built on later to support something other than `config` if we choose to, or add support for merging configs from multiple sources since everything is optional. ### Drive-by changes - Default to `http` for connection type - Default to no gas payment enforcement if not specified instead of failing - `ChainSetup` -> `ChainConf` - `GasPaymentEnforcementConfig` -> `GasPaymentEnforcementConf` - Made ethereum connection configuration more forgiving - Moved hyperlane base settings from `mod.rs` to `base.rs` - Moved config chain tests in hyperlane core to `tests` dir to fix a cyclical import problem - Extension traits to help with config in hyperlane core - Moved `StrOrInt` to new hyperlane core `config` module - Support for parsing `U256` from `StrOrInt` - Removed `HexString` type which is now redundant - Updated base settings to use hyperlane domain - Use `heyKey` as signer type if `type` is not specified and `key` is - Moved hyperlane ethereum chain config to a new module ### Related issues - Fixes #2033 - Fixes #2012 ### Backward compatibility _Are these changes backward compatible?_ Yes - This should take in configs in the same shape but be more forgiving in a few places _Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling?_ None ### Testing _What kind of testing have these changes undergone?_ Manual Unit Test
2 years ago
use std::collections::BTreeSet;
use std::fs::read_to_string;
use std::path::Path;
use config::{Config, FileFormat};
use eyre::Context;
Better Agent Configuration Parsing (#2070) ### Description This is a significant change to how we parse user configs. The main goal of this PR is to give a clear path and env key to any errors that are encountered when parsing configuration. In order to accomplish this, I have crated a new trait `FromRawConf` which defines a set of steps to validate and convert individual fields. Also for every major config struct, there is now a `Raw*` variant of it which is used by the `config` library to reduce errors that occur during deserialization itself. `Raw*` types should always use the most basic form of a value, such as `String`, `StrOrInt`, `bool`, and ideally optional in all cases. Missing values should be handled during the raw conversion and not by `config`. I also needed to make changes to a number of types stored in the parsed config types to force validation forward to the parsing step instead of doing it when we read the config value. This also required me to create a filter to prevent trying to validate certain configs that we would not ever need to load. These changes can also be built on later to support something other than `config` if we choose to, or add support for merging configs from multiple sources since everything is optional. ### Drive-by changes - Default to `http` for connection type - Default to no gas payment enforcement if not specified instead of failing - `ChainSetup` -> `ChainConf` - `GasPaymentEnforcementConfig` -> `GasPaymentEnforcementConf` - Made ethereum connection configuration more forgiving - Moved hyperlane base settings from `mod.rs` to `base.rs` - Moved config chain tests in hyperlane core to `tests` dir to fix a cyclical import problem - Extension traits to help with config in hyperlane core - Moved `StrOrInt` to new hyperlane core `config` module - Support for parsing `U256` from `StrOrInt` - Removed `HexString` type which is now redundant - Updated base settings to use hyperlane domain - Use `heyKey` as signer type if `type` is not specified and `key` is - Moved hyperlane ethereum chain config to a new module ### Related issues - Fixes #2033 - Fixes #2012 ### Backward compatibility _Are these changes backward compatible?_ Yes - This should take in configs in the same shape but be more forgiving in a few places _Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling?_ None ### Testing _What kind of testing have these changes undergone?_ Manual Unit Test
2 years ago
use walkdir::WalkDir;
use hyperlane_base::{RawSettings, Settings};
use hyperlane_core::config::*;
use hyperlane_core::KnownHyperlaneDomain;
/// Relative path to the `hyperlane-monorepo/rust/config/`
/// directory, which is where the agent's config files
/// currently live.
const AGENT_CONFIG_PATH_ROOT: &str = "../config";
/// We will not include any file paths of config/settings files
/// in the test suite if *any* substring of the file path matches
/// against one of the strings included in the blacklist below.
/// This is to ensure that e.g. when a backwards-incompatible
/// change is made in config file format, and agents can't parse
/// them anymore, we don't fail the test. (E.g. agents cannot
/// currently parse the older files in `config/dev/` or
/// `config/testnet`.
const BLACKLISTED_DIRS: &[&str] = &[
// Ignore only-local names of fake chains used by
// e.g. test suites.
"test/test_config.json",
];
fn is_blacklisted(path: &Path) -> bool {
BLACKLISTED_DIRS
.iter()
.any(|x| path.to_str().unwrap().contains(x))
}
#[derive(Clone, Debug, Ord, PartialEq, PartialOrd, Eq, Hash)]
struct ChainCoordinate {
name: String,
domain: u32,
}
fn config_paths(root: &Path) -> Vec<String> {
WalkDir::new(root)
.min_depth(2)
.into_iter()
.filter_map(|x| x.ok())
.map(|x| x.into_path())
.filter(|x| !is_blacklisted(x))
.map(|x| x.into_os_string())
.filter_map(|x| x.into_string().ok())
.collect()
}
/// Provides a vector of parsed `hyperlane_base::Settings` objects
/// built from all of the version-controlled agent configuration files.
/// This is purely a utility to allow us to test a handful of critical
/// properties related to those configs and shouldn't be used outside
/// of a test env. This test simply tries to do some sanity checks
/// against the integrity of that data.
fn hyperlane_settings() -> Vec<Settings> {
let root = Path::new(AGENT_CONFIG_PATH_ROOT);
let paths = config_paths(root);
let files: Vec<String> = paths
.iter()
.filter_map(|x| read_to_string(x).ok())
.collect();
paths
.iter()
.zip(files.iter())
.map(|(p, f)| {
let raw: RawSettings = Config::builder()
.add_source(config::File::from_str(f.as_str(), FileFormat::Json))
.build()
.unwrap()
.try_deserialize::<RawSettings>()
.unwrap_or_else(|e| {
panic!("!cfg({}): {:?}: {}", p, e, f);
});
Settings::from_config(raw, &ConfigPath::default())
.context("Config parsing error, please check the config reference (https://docs.hyperlane.xyz/docs/operators/agent-configuration/reference)")
.unwrap()
Better Agent Configuration Parsing (#2070) ### Description This is a significant change to how we parse user configs. The main goal of this PR is to give a clear path and env key to any errors that are encountered when parsing configuration. In order to accomplish this, I have crated a new trait `FromRawConf` which defines a set of steps to validate and convert individual fields. Also for every major config struct, there is now a `Raw*` variant of it which is used by the `config` library to reduce errors that occur during deserialization itself. `Raw*` types should always use the most basic form of a value, such as `String`, `StrOrInt`, `bool`, and ideally optional in all cases. Missing values should be handled during the raw conversion and not by `config`. I also needed to make changes to a number of types stored in the parsed config types to force validation forward to the parsing step instead of doing it when we read the config value. This also required me to create a filter to prevent trying to validate certain configs that we would not ever need to load. These changes can also be built on later to support something other than `config` if we choose to, or add support for merging configs from multiple sources since everything is optional. ### Drive-by changes - Default to `http` for connection type - Default to no gas payment enforcement if not specified instead of failing - `ChainSetup` -> `ChainConf` - `GasPaymentEnforcementConfig` -> `GasPaymentEnforcementConf` - Made ethereum connection configuration more forgiving - Moved hyperlane base settings from `mod.rs` to `base.rs` - Moved config chain tests in hyperlane core to `tests` dir to fix a cyclical import problem - Extension traits to help with config in hyperlane core - Moved `StrOrInt` to new hyperlane core `config` module - Support for parsing `U256` from `StrOrInt` - Removed `HexString` type which is now redundant - Updated base settings to use hyperlane domain - Use `heyKey` as signer type if `type` is not specified and `key` is - Moved hyperlane ethereum chain config to a new module ### Related issues - Fixes #2033 - Fixes #2012 ### Backward compatibility _Are these changes backward compatible?_ Yes - This should take in configs in the same shape but be more forgiving in a few places _Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling?_ None ### Testing _What kind of testing have these changes undergone?_ Manual Unit Test
2 years ago
})
.collect()
}
fn chain_name_domain_records() -> BTreeSet<ChainCoordinate> {
hyperlane_settings()
.iter()
.flat_map(|x: &Settings| {
x.chains.values().map(|v| ChainCoordinate {
name: v.domain.name().into(),
domain: (&v.domain).try_into().expect("Invalid domain id"),
})
})
.collect()
}
#[test]
fn agent_json_config_consistency_checks() {
// Verify that the hard-coded, macro-maintained
// mapping in `hyperlane-core/src/chain.rs` named
// by the macro `domain_and_chain` is complete
// and in agreement with our on-disk json-based
// configuration data.
let chain_coords = chain_name_domain_records();
for ChainCoordinate { name, domain } in chain_coords.into_iter() {
assert_eq!(
KnownHyperlaneDomain::try_from(domain).unwrap().to_string(),
name
);
assert_eq!(name.parse::<KnownHyperlaneDomain>().unwrap() as u32, domain);
}
}