You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The transaction to simulate was AAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAGAAAAAAAAAABqcyWObpdzFnUSN332FhvsFmwI8FSWHo/kRyy069qW5AAAAAGZGVwbG95AAAAAAACAAAADQAAABR9sHVzOQysoq5eXe/f+3AfT9WolQAAAA0AAABBBJFhCrhmp0SLcac+YTROcq+SKautVIDzg59ppjN7hir1Imo00C0b0uDYr/KDd4duQdSCqtfVFGR5H2yMmg1zxrgAAAAAAAAAAAAAAAAAAAA=
What did you expect to see?
No empty (NoneNone ) pairs in the modified_entries vector of InvokeHostFunctionSimulationResult
What did you see instead?
This code:
let invoke_hf_result = simulate_invoke_host_function_op(
auto_restore_snapshot.clone(),&network_config,&adjustment_config,&ledger_info,
invoke_hf_op.host_function,
auth_entries,&source_account,
rand::Rng::gen(&mut rand::thread_rng()),
enable_debug,)?;for e in invoke_hf_result.modified_entries.iter(){println!("{:?}, {:?}",e.state_before, e.state_after);}
Upon investigation it seems that there is no issue here. While None, None case seems confusing, it conforms to the semantics of the diffs, which is:
The first value is None when entry wasn't present in storage before contract execution
The second value is None when entry wasn't present in storage after contract execution
When both values are None, it would mean that the key hasn't existed before contract execution, then there was a number of write operations for the corresponding key, but the key doesn't have a persisted value after contract execution. Note, that remove is a write operation as well, so removing a non-existent entry will also result in None, None diff (on a side note, this is a bit inefficient and can be optimized at the SDK level).
I think this is actually a pretty useful signal, as the user still needs to pay for an RW footprint entry, but doesn't actually persist it. There also might be bugs where the user expected a new entry to be created, but it hasn't been persisted for some reason. So the library shouldn't be modified, but we might want to flag this somehow in the response to raise the users' awareness.
What version are you using?
soroban-simulation 21.1.0 (through soroban-rpc)
What did you do?
See stellar/soroban-rpc#239
The transaction to simulate was
AAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAGAAAAAAAAAABqcyWObpdzFnUSN332FhvsFmwI8FSWHo/kRyy069qW5AAAAAGZGVwbG95AAAAAAACAAAADQAAABR9sHVzOQysoq5eXe/f+3AfT9WolQAAAA0AAABBBJFhCrhmp0SLcac+YTROcq+SKautVIDzg59ppjN7hir1Imo00C0b0uDYr/KDd4duQdSCqtfVFGR5H2yMmg1zxrgAAAAAAAAAAAAAAAAAAAA=
What did you expect to see?
No empty (
None
None
) pairs in themodified_entries
vector ofInvokeHostFunctionSimulationResult
What did you see instead?
This code:
Printed:
Note the first
None, None
pairThe text was updated successfully, but these errors were encountered: