Skip to content
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

Exception Handling in submit_and_wait Loses Valuable Transaction Metadata #797

Closed
Skelectric opened this issue Jan 10, 2025 · 3 comments
Closed

Comments

@Skelectric
Copy link

Issue

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:

  1. Return a response object that includes success/failure status and full transaction metadata, rather than raising an exception
  2. 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         
@mvadari
Copy link
Collaborator

mvadari commented Jan 10, 2025

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.

@Skelectric
Copy link
Author

Skelectric commented Jan 10, 2025

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.

@mvadari
Copy link
Collaborator

mvadari commented Jan 13, 2025

You can get most of that information if you autofill/sign separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants