Feature request
I would like to get meaningful errors when I pass configuration (via JSON, ENV vars or both) to Iroha 2.
Consider the following cases that currently occur:
-
I have passed PUBLIC_KEY and PRIVATE_KEY env vars, and I get an error:
Please add PUBLIC_KEY and PRIVATE_KEY to the configuration.
It turned out that yes, in JSON configuration I could provide them as top-level fields with these names, but when it comes to ENV, I should specify them as IROHA_PUBLIC_KEY and IROHA_PRIVATE_KEY.
By the way: yes, it prints exactly "PUBLIC_KEY AND PRIVATE_KEY", not "PUBLIC_KEY and PRIVATE_KEY".
The descriptive error would be:
Please add PUBLIC_KEY (env: IROHA_PUBLIC_KEY) and PRIVATE_KEY (env: IROHA_PRIVATE_KEY) fields to the configuration.
-
I forgot to specify the P2P addr:
Please add p2p_addr to the configuration.
The descriptive error would be:
Please add TORII.P2P_ADDR (env: TORII_P2P_ADDR) to the configuration.
Thoughts on implementation
Introduce a data structure for configuration parameter location:
struct Location {
env_var: &'static str,
serde: &'static str
}Then refactor the configuration proc macros so they can generate all of the locations in order to use them statically.
Sample macro usage:
#[derive(Proxy)]
#[proxy(locations = "config_locations_private", env_prefix = "IROHA_")]
struct Iroha {
public_key: PublicKey,
sumeragi: Sumeragi
}
#[derive(Proxy)]
#[proxy(env_prefix = "SUMERAGI_")]
struct Sumeragi {
p2p_addr: String
}Generated modules
// by proc macro
mod config_locations_private {
use crate::Location;
pub const public_key: Location = Location {
env_var: "IROHA_PUBLIC_KEY",
serde: "PUBLIC_KEY"
}
pub mod sumeragi {
pub const p2p_addr: Location = Location {
env_var: "SUMERAGI.P2P_ADDR",
serde: "SUMERAGI_P2P_ADDR"
}
}
}
// visibility control, if needed
pub mod config_locations {
pub use super::config_locations_private;
}Then, this code could be used in other parts to throw descriptive errors, like that:
if let (Some(public_key), Some(private_key)) = (&self.public_key, &self.private_key) {
// ...
} else {
return Err(ConfigError::MissingParameters {
locations: vec![config_locations::public_key, config_locations::private_key]
});
}Motivation
Iroha will be even more useful if it throws descriptive and helpful errors when misconfiguration happens.
Also, it will be useful for #2373 - the tool will be able to define ENV variables in a docker-compose configuration with static check.
Who can help?
No response
Feature request
I would like to get meaningful errors when I pass configuration (via JSON, ENV vars or both) to Iroha 2.
Consider the following cases that currently occur:
I have passed
PUBLIC_KEYandPRIVATE_KEYenv vars, and I get an error:It turned out that yes, in JSON configuration I could provide them as top-level fields with these names, but when it comes to ENV, I should specify them as
IROHA_PUBLIC_KEYandIROHA_PRIVATE_KEY.By the way: yes, it prints exactly "
PUBLIC_KEY AND PRIVATE_KEY", not "PUBLIC_KEYandPRIVATE_KEY".The descriptive error would be:
I forgot to specify the P2P addr:
The descriptive error would be:
Thoughts on implementation
Introduce a data structure for configuration parameter location:
Then refactor the configuration proc macros so they can generate all of the locations in order to use them statically.
Sample macro usage:
Generated modules
Then, this code could be used in other parts to throw descriptive errors, like that:
Motivation
Iroha will be even more useful if it throws descriptive and helpful errors when misconfiguration happens.
Also, it will be useful for #2373 - the tool will be able to define ENV variables in a docker-compose configuration with static check.
Who can help?
No response