-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize Insufficient TRX Error Message of Multi-Sign Transaction #5736
Comments
Nice, I support option one |
+1, The error message is clear |
Is it possible to determine the account type during the query and return the correct amount of available resources? |
@tomatoishealthy |
Considering that the abnormal information thrown by option 2 may cause ambiguity, option 1 will be used to optimize this issue. |
|
@YuMenGuan |
For this issue, further assessment will be conducted on the current error message return mechanism to identify the most suitable improvement direction. Ensuring better compatibility in future version updates is a priority. |
Rationale
Currently, when users try to query the maximum delegated bandwidth through the
/wallet/getcandelegatedmaxsize
interface, they find that the bandwidth margin is sufficient. However, when using the/wallet/delegateresource
interface for delegateing resource, they may encounter an error message "Account resource insufficient error." After investigation, it was found that the actual reason for this error is not insufficient bandwidth resources, but insufficient transaction (TRX) balance in the account. This is because this transaction is a multi signature transaction, and the transaction cost of the multi signature operation needs to be deducted from the TRX balance of the account.The current issue lies in the broad and sometimes inaccurate definition of the exception thrown. This can lead to confusion and misunderstanding among users, who may wrongly believe that they need to purchase more bandwidth resources instead of simply topping up their TRX balance.
To address this, we propose two solutions:
Implementation
Solution 1: Replacing the exception type
Identify the current exception class being thrown for the "Account resource insufficient" error.
Currently, there is an exception type called "BalanceInsufficientException", which can be used instead of the previously misreported "AccountResourceInsufficientException", specifically for the case of insufficient TRX balance for multi-signature transactions.
Update the relevant code paths within the specific implementation to throw this new exception type when the TRX balance is insufficient.
Update the error handling and messaging systems to recognize and display the new exception type with an appropriate error message.
Solution 2: Extending the Existing Exception Type
Identify the current exception class being thrown for the "Account resource insufficient" error.
Modify the exception class's description or message to include the possibility of insufficient TRX balance for multi-signature transactions, perhaps by adding an "or" clause.
Update the relevant code paths within the specific implementation to throw this modified exception when either the bandwidth resources or the TRX balance is insufficient.
Update the error handling and messaging systems to recognize and display the modified exception with an appropriate error message.
Either solution would help improve the user experience by providing a more accurate and useful error message in the case of insufficient TRX balance for multi-signature transactions.
The text was updated successfully, but these errors were encountered: