Add UI handling for TX error message

[lealobanov]

Related Issue

Add UI handling for TX error message

Summary of Changes

Need Regression Testing

• Yes
• No

Risk Assessment

• Low
• Medium
• High

Additional Notes

Screenshots (if applicable)

[github-actions]

PR Summary

Enhanced transaction status validation by incorporating error message checks across different transaction types. Updated the success criteria to ensure transactions are only considered successful when both execution status is successful AND error message is blank. This improvement affects regular transactions, bridge transactions, and multi-signature transactions.

Changes

File	Summary
app/build.gradle	Upgraded com.github.onflow.flow-kmm:flow dependency from version 0.0.24 to 0.0.25 to support new error handling features.
app/src/main/java/com/flowfoundation/wallet/manager/flowjvm/transaction/Transaction.kt	Enhanced transaction success validation in sendTransaction, sendBridgeTransaction, and sendTransactionWithMultiSignature methods by adding errorMessage.isBlank() check alongside execution status for FINALIZED, SEALED, and EXECUTED states.

---

autogenerated by presubmit.ai

[github-actions]

🚨 Pull request needs attention.

Review Summary

Commits Considered (2)

• e3f967a: Error handling for tx status with error message
• ffa8fad: Bump flow-kmm

Files Processed (2)

• app/build.gradle (1 hunk)
• app/src/main/java/com/flowfoundation/wallet/manager/flowjvm/transaction/Transaction.kt (3 hunks)

Actionable Comments (1)

• app/build.gradle [369-369]

  possible issue: "Version upgrade might introduce breaking changes"

Skipped Comments (2)

• app/src/main/java/com/flowfoundation/wallet/manager/flowjvm/transaction/Transaction.kt [98-99]

  enhancement: "Consider handling non-blank error messages"

• app/src/main/java/com/flowfoundation/wallet/manager/flowjvm/transaction/Transaction.kt [95-104]

  maintainability: "Duplicate transaction status handling logic"

[github-actions]

The Flow KMM SDK is being upgraded from version 0.0.24 to 0.0.25. Given the early version numbers (0.0.x), this could potentially introduce breaking changes. Ensure all SDK functionality is thoroughly tested after this upgrade.