Getting wallet information in a step and populating an accounts array, which is shared between every step.
We assume that the genesis account with many Algos exist in the first index of the accounts array. So we transfer some algos from accounts[0] to the account we want to fund.
But when we rekey accounts, the accounts in the wallet might be switched around (non-deterministically?). So when we get the wallet information again, accounts[0] might not be the genesis account and may have been replaced by an underfunded account.
This can cause flaky tests and cause overspending errors if the wrong account is selected and seems to affect all 4 SDKs.
Solution
Our current solution is to fund the rekeyed account with a semi-large amount of Algos so that every account we pull from has (hopefully) enough Algos to fund other accounts. We currently do this in the Python and JS SDK. Example in Python SDK. This might not be enough to protect future tests/steps that require more accounts with more Algos.
A better long term solution is not to depend on accounts[0] holding the genesis account with lots of Algos. We can create a separate genesis_account global/context object that holds the pk-sk pair, and fund accounts using that. Then, we can replace every instance of accounts[0] with the genesis_account instead.
Urgency
There is a temporary solution to this, but may cause flaky tests in the future if we add more tests/steps involving account funding.
Problem
Currently, we fund accounts by:
wallet informationin a step and populating anaccountsarray, which is shared between every step.accountsarray. So we transfer some algos fromaccounts[0]to the account we want to fund.But when we rekey accounts, the accounts in the wallet might be switched around (non-deterministically?). So when we get the wallet information again,
accounts[0]might not be the genesis account and may have been replaced by an underfunded account.This can cause flaky tests and cause overspending errors if the wrong account is selected and seems to affect all 4 SDKs.
Solution
Our current solution is to fund the rekeyed account with a semi-large amount of Algos so that every account we pull from has (hopefully) enough Algos to fund other accounts. We currently do this in the Python and JS SDK. Example in Python SDK. This might not be enough to protect future tests/steps that require more accounts with more Algos.
A better long term solution is not to depend on
accounts[0]holding the genesis account with lots of Algos. We can create a separategenesis_accountglobal/context object that holds the pk-sk pair, and fund accounts using that. Then, we can replace every instance ofaccounts[0]with thegenesis_accountinstead.Urgency
There is a temporary solution to this, but may cause flaky tests in the future if we add more tests/steps involving account funding.