...

1. Verify voters2 table contents match what was in voters before the migration

2. Register a producer

3. Register fio_address for producer

4. Vote for the producer

5. Verify owner and fio_address are populated as a voter in the accounts voters2 record

6. Verify voting still works and no regression

Plan:

• TODO: Add the post table migration tests above to vote.js. Confirm running them at all phases of contract rollout.

Performance Testing plan

• Voteproducer stress testing should be done on voters table before the migration, then voter2 table after the migration. Results will be compared.

• Tests carried out on devnet, testnet before deployment to mainnet

...

• Completed work on table migration. In testing phase. fio.system contract (eosio account) has been updated with the following features:

  • Voteproducer calls will only migrate 3 vote records over from voters to voters2 table at a time. After the approximate 83 records are moved over, the voteproducer action will function again.

  • The migration logic will not execute so long as the old voters table stays empty, which should be indefinite or until the contract is updated with the migration logic removed.

  • All contracts will now use “voters2” in state.

  • The data should be exact, and the producers that a voter has voted for will not have the respective fio_address item populated for the producer that was voted for at the time previous to the migration. This will be updated on that users next call to voteproducer.
    https://github.com/fioprotocol/fio.contracts/pull/33/files

• v1/chain/get_account has been updated to search the voters table first, and then the voters2 table. If there is no result from either table the voter_info is treated as null as before.
  https://github.com/fioprotocol/fio/pull/230/