near-sdk-sim 3.2.0: Expose cur block and fix storage costs #390
Conversation
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
near-sdk-sim/src/runtime.rs
Outdated
| @@ -268,7 +271,7 @@ impl RuntimeStandalone { | |||
| random_seed: Default::default(), | |||
| epoch_id: EpochId::default(), | |||
| current_protocol_version: PROTOCOL_VERSION, | |||
| config: Arc::from(self.genesis.runtime_config.clone()), | |||
| config: RuntimeConfig::from_protocol_version(&self.runtime_config, PROTOCOL_VERSION), | |||
There was a problem hiding this comment.
The thing with lazy_static that happens inside RuntimeConfig::from_protocol_version feels a bit odd. Seems like tests might start with different genesiss_config, and then config of one test will override config of the other?
There was a problem hiding this comment.
🤔 I think that's exactly the reason why near/nearcore#4263 fails
There was a problem hiding this comment.
Added a fix for that to near/nearcore#4263 (not that we can immediately use that in the SDK)
There was a problem hiding this comment.
It was mostly for mainnet upgrade. I guess we can also override Default for GenesisConfig to use this instead of applying it in the produce block. This way the user can override the config if needed.
near-sdk-sim/src/runtime.rs
Outdated
| pub genesis: GenesisConfig, | ||
| tx_pool: TransactionPool, | ||
| transactions: HashMap<CryptoHash, SignedTransaction>, | ||
| outcomes: HashMap<CryptoHash, ExecutionOutcome>, | ||
| profile: HashMap<CryptoHash, ProfileData>, | ||
| cur_block: Block, | ||
| pub cur_block: Block, | ||
| runtime: Runtime, | ||
| tries: ShardTries, | ||
| pending_receipts: Vec<Receipt>, | ||
| epoch_info_provider: Box<dyn EpochInfoProvider>, | ||
| pub last_outcomes: Vec<CryptoHash>, | ||
| pub runtime_config: Arc<RuntimeConfig>, |
There was a problem hiding this comment.
out of curiosity, what is the need for these three to be public now? Would you mind linking to where they are used externally?
There was a problem hiding this comment.
Since this is for tests only, it worth give more control to the user. cur_block should be exposed as is and there is no reason to hide it from the user. The main idea is you should have granular control over block time. For example when testing lockup contracts we need to check what would be the balance after a year. For staking pool we want to have access to epoch ID. But if we rely only on produce block advancing this variables, it's hard to write assert statements because you either should replicate math in tests, or just hardcode the output without verifying math. But if you have precise time control, then you can just use round numbers.
There was a problem hiding this comment.
yeah I was just curious what the interactions would look like to explore if there is an alternative that's easier to maintain/use
cur_blockandgenesis_configfromRuntimeStandalone. This allows to manipulate block time, e.g. set to a given timestamp.RuntimeConfig::from_protocol_versionthat fixes storage costs issue. Fixes: near-sdk-sim calculates storage incorrectly #388Test plan: