Open lxcmyf opened 8 months ago
Nice, I support option one
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?
Is it possible to determine the account type during the query and return the correct amount of available resources?
@tomatoishealthy This may not be related to the account type, as this transaction is a multi signature transaction, so an additional deduction of account TRX is required, and this fee consumption is not deducted from the available bandwidth of the account.
Considering that the abnormal information thrown by option 2 may cause ambiguity, option 1 will be used to optimize this issue.
Considering that the abnormal information thrown by option 2 may cause ambiguity, option 1 will be used to optimize this issue. @lxcmyf
Option 1 is also my choose. But I have another question, whether the error message can contain the information of minimum quantity of TRX the account should have.
@YuMenGuan It's feasible, good advice.
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.