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
After a discussion on the pull request threshold-network/token-dashboard#537 (comment), it has been proposed to improve the user experience on the Threshold Dashboard by separating the _totalRetryAttempts parameter into separate variables for read and write transactions.
Currently, there is an issue where executing a transaction (such as a redemption request) and subsequently rejecting it with the wallet triggers the transaction to fire again after approximately 3 seconds. If the rejection occurs again, it appears as an endless loop. To identify the user rejection error, it requires rejecting the transaction four times. This situation is undesirable, and we aim to enhance the user experience.
To address this issue, we propose implementing separate retry variables for signing transactions and reading transactions. This separation will allow us to utilize the retry functionality effectively when reading data, while avoiding the repetitive transaction firing during rejection scenarios.
The text was updated successfully, but these errors were encountered:
michalsmiarowski
changed the title
TS: Split _totalRetryAttempts parameter into separate variables for reand and write transactions
TS: Split _totalRetryAttempts parameter into separate variables for read and write transactions
Jul 12, 2023
After a discussion on the pull request threshold-network/token-dashboard#537 (comment), it has been proposed to improve the user experience on the Threshold Dashboard by separating the
_totalRetryAttempts
parameter into separate variables for read and write transactions.Currently, there is an issue where executing a transaction (such as a redemption request) and subsequently rejecting it with the wallet triggers the transaction to fire again after approximately 3 seconds. If the rejection occurs again, it appears as an endless loop. To identify the user rejection error, it requires rejecting the transaction four times. This situation is undesirable, and we aim to enhance the user experience.
To address this issue, we propose implementing separate retry variables for signing transactions and reading transactions. This separation will allow us to utilize the retry functionality effectively when reading data, while avoiding the repetitive transaction firing during rejection scenarios.
The text was updated successfully, but these errors were encountered: