fix: use global storage instead of transactions or blocks iterator to perform accounts iteration #156
Conversation
… check state keys for non-senders as well.
| // reset the states of the movement migrator | ||
| info!("Resetting movement migrator states"); | ||
| movement_migrator | ||
| .reset_states() |
There was a problem hiding this comment.
Why do we need to reset the MovementMigrator? Each check calls checked_migration() with a fresh instance.
There was a problem hiding this comment.
Yes, because the state can be filled during the first run. Then, another clone can be dropped causing the application to be shut down. Finally, the states represented in the struct do not actually represent the state of the application.
The better thing to do would probably be to place reset_states in the drop implementation itself. However, I might have to be a little clever to get around async in sync issues.
| info!("Getting next transaction from block iterator"); | ||
| if let Some(iter) = &mut self.current_block_iter { | ||
| if let Some(tx) = iter.next() { | ||
| info!("Got next transaction from block iterator {:?}", tx); |
There was a problem hiding this comment.
Perhaps use debug!() since there will be a large number of transactions.
There was a problem hiding this comment.
Yeah, good call.
Summary
The previous
AccountsIteratorrelied on checking senders of transactions. This does not, in fact, account for accounts which have been created but have not yet sent a transaction--as is often the case with drops.Warning
The errors in multiprocessing have been requested for revisit under #158, i.e., in a follow-on PR.