Hi,
However, when the user cancels the transaction , the error callback/action is not triggered . The same issue occurs with the success callback , as it is not being fired consistently after a successful transaction.
Please refer to the screenshots below for more details:
Could you please help identify why the cancel and success actions are not working as expected, and advise on the correct way to handle these callbacks in WalletConnect v5.0.7?
Thank you for your support.
MetaMask - RPC Error: MetaMask Tx Signature: User denied transaction signature. {code: 4001, message: ‘MetaMask Tx Signature: User denied transaction signature.’, data: {…}, stack: ‘{\n “code”: 4001,\n “message”: "MetaMask Tx Signat…hfbeogaeaoehlefnkodbefgpgknn/common-2.js:3:142239’}
Thanks for your detailed message and for sharing the screenshots - we appreciate the context.
Regarding the behavior you’re seeing with WalletConnect v5.0.7, this is expected and comes down to how wallet-side actions are handled. When a user cancels or rejects a transaction in the wallet (for example, MetaMask returning error code 4001 – User denied transaction signature), this action happens entirely inside the wallet UI. In these cases, WalletConnect does not always propagate the rejection back to Bubble as a plugin “error,” so the Error element event may not fire.
Similarly, the Success event is only triggered when the transaction is successfully signed and submitted by the wallet, which can make it feel inconsistent if the user closes or rejects the wallet prompt.
Due to these limitations, we recommend handling transaction flow using a state-based approach in Bubble, rather than relying solely on the Success/Error callbacks.
A common pattern is to set a custom state (for example, transaction_status = pending) before sending the transaction, update it to success when the Success event fires, and use a fallback or timeout workflow to treat unresolved pending states as canceled. This mirrors how most Web3 applications handle wallet rejections and interruptions.
Could you please let us know which network you’re using and whether you’ve observed the same behavior with other wallets (for example, WalletConnect QR-based wallets versus MetaMask)?
This will help us confirm if there are any wallet-specific nuances worth flagging.
Thank you again for taking the time to report this and for your patience. We’re always happy to help clarify expected behavior and best practices.
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble
Just a quick follow-up to check if you had a chance to review our previous message and try the suggested state-based handling approach.
Could you please let us know:
This will help us confirm whether there are any wallet- or network-specific nuances we should look into further.
Thanks again, and feel free to reach out if you have any follow-up questions - we’re happy to help.
Best regards,
Support Team
Browse all Zeroqode Plugins for bubble