Currently, a new build is fired as soon as any change to the user input is noticed, ie address, ada amount, or asset input.
If an updated tx build request is sent within 10ms of the first one, updated will replace previous. But if it goes more than 10ms in between, we could end up in case where there is a build running and a second build request arrive. If first build haven't completd within 10ms cooldown of updated build request, a second build will be initiated while previous is still ongoing causing additional strain on resources as well as potential race conditions where a later build finish before first and thus the final built tx doesn't reflect users last input.
Utxo list is fetched from db over and over causing strain if I/O performance is limited and utxo set is large.
Solution:
Cancelable transaction building. Make tx counter global to know if there are any newer build requests made. After each await in build pipeline, check if current build should be cancelled or not.
Cache utxo list for current selected account to not have to re-fetch from db over and over. In utxo store, keep track of selected account and update utxo list on account change and/or account sync report changes in utxo set.
Scitz0
commented
5 months ago
Problems:
Solution: