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
When submit_and_wait encounters a failed transaction, it raises an XRPLReliableSubmissionException without providing access to the underlying transaction metadata. This makes it difficult for applications to handle failed transactions gracefully or inspect the detailed reason for failure.
Current Behavior
try:
response = xrpl.transaction.submit_and_wait(payment, client, wallet)
return response
except xrpl.transaction.XRPLReliableSubmissionException as e:
# No access to transaction metadata here
logger.error(f"Transaction submission failed: {e}")
raise
When a transaction fails, the exception is raised before the response object can be accessed, even though the underlying API calls have gathered valuable metadata about the transaction status.
Desired Behavior
Ideally, submit_and_wait should either:
Return a response object that includes success/failure status and full transaction metadata, rather than raising an exception
Include the full response object in the exception when raised
This would allow applications to:
Access detailed transaction metadata regardless of success/failure
Make informed decisions based on specific failure conditions
Provide better error reporting to users
Implement more sophisticated retry logic
Solution
Here's one possible approach that maintains backward compatibility while providing access to transaction metadata:
class XRPLReliableSubmissionException(XRPLException):
"""Enhanced exception that preserves transaction metadata"""
def __init__(self, message: str, response: Optional[Response] = None):
super().__init__(message)
self.response = response
async def submit_and_wait(
transaction: Union[Transaction, str],
client: Client,
wallet: Optional[Wallet] = None,
*,
check_fee: bool = True,
autofill: bool = True,
fail_hard: bool = False,
) -> Response:
"""
Submit a transaction and wait for validation. Returns response on success,
raises enhanced exception with metadata on failure.
"""
signed_transaction = await _get_signed_tx(
transaction, client, wallet, check_fee, autofill
)
try:
return await _send_reliable_submission(
signed_transaction, client, fail_hard=fail_hard
)
except XRPLReliableSubmissionException as e:
# Enhance exception with transaction metadata if available
tx_hash = signed_transaction.get_hash()
try:
tx_response = await client._request_impl(Tx(transaction=tx_hash))
raise XRPLReliableSubmissionException(str(e), response=tx_response)
except:
raise e # If we can't get metadata, raise original exception
The text was updated successfully, but these errors were encountered:
Can you provide an example for why you want the full response? The response always provides the error code, and only tec errors will have metadata to show.
Knowing that a transaction failed with a specific error code is not enough context. The full response includes information like
Exact state of the transaction at time of failure
Any warnings or additional messages
transaction hash
ledger sequence number
fee information
Without the response object, I have to have the websocket running at the same time, parse the tx info as it comes in, and attempt to match it against the transaction I just tried to submit. This is far from ideal.
Issue
When
submit_and_wait
encounters a failed transaction, it raises anXRPLReliableSubmissionException
without providing access to the underlying transaction metadata. This makes it difficult for applications to handle failed transactions gracefully or inspect the detailed reason for failure.Current Behavior
When a transaction fails, the exception is raised before the response object can be accessed, even though the underlying API calls have gathered valuable metadata about the transaction status.
Desired Behavior
Ideally,
submit_and_wait
should either:This would allow applications to:
Solution
Here's one possible approach that maintains backward compatibility while providing access to transaction metadata:
The text was updated successfully, but these errors were encountered: