wait for RPC hash before showing success screen

[n13]

• send without waiting for server was an over-optimization which led to bad edge cases - if a tx hash is returned, the tx will most likely work
• show full address in send confirmation - this is a security feature

[dewabisma]

LGTM!

[n13]

I've reviewed PR #524 against the actual code. Here's my assessment.

Summary

The PR makes two scoped changes:

1. submitAndTrackTransaction now awaits the submission and the returned extrinsic hash before completing (previously fire-and-forget via unawaited(_submitAndTrackBackground(...))), and rethrows on failure so the caller surfaces the error instead of optimistically navigating to the success screen.
2. review_send_screen.dart shows the full recipient address in the summary "To" row instead of the truncated form.

Overall this is a sound, well-reasoned change. A few things worth flagging.

What's good

• Aligns with fail-early: errors now propagate to _confirmSend's catch and show sendReviewSubmitFailed, instead of being swallowed in a background future. This matches the project's "no silent failure" rule better than the old behavior.
• Dead-code cleanup: the old failure branch did updateState(..., failed, ...) immediately followed by remove(...), so the failed-state write was pointless. The new code just remove(...) + rethrow. Cleaner.
• The double-spend / single-sign retry safety comment is preserved, and the docstring is updated accurately.

Issues

1. Unguarded setState on the success path (should fix) — review_send_screen.dart:86

    try {
      ...
      await submissionService.balanceTransfer(...);
      unawaited(RecentAddressesService()...);
      setState(() {            // <-- no `mounted` check
        _submitting = false;
        _errorMessage = null;
      });

      if (mounted) {
        Navigator.push(...);
      }

Previously the await returned almost instantly, so unmount-during-await was effectively impossible. Now the await genuinely blocks on an RPC round-trip (plus up to 3 retries with backoff). That widens the unmount window a lot. If the widget unmounts during submission, this setState throws, gets caught by the catch at line 104, which logs Transfer failed and would show the failure message — i.e. a successful send gets routed into the failure path and the success screen is never shown. Recommend if (!mounted) return; before the success setState (the catch already guards its setState with mounted).

2. No bounded timeout now that the UI blocks on submit (consideration)

submitExtrinsic retries up to 3× with 500ms * attempt backoff across redundant endpoints (substrate_service.dart:181), relying on the underlying HTTP client's timeout. Since the confirm button now blocks on this, a hung/slow endpoint means the spinner can hang for a while. Given the "fail early" rule, consider a bounded .timeout(...) so the user gets a clear failure rather than an indefinite spinner.

3. Optimistic pattern still used elsewhere (consistency / out of scope?)

The multisig flows (proposeTransfer, approveProposal, executeProposal, cancelProposal, and multisig_submission_service._submitAndTrackBackground) still use the unawaited(...) fire-and-forget pattern this PR is explicitly moving away from. The same "over-optimization → bad edge cases" rationale applies to them. Fine to leave out of scope, but worth a follow-up so the codebase converges on one pattern.

4. Two address representations on one screen (minor/UI)

On the review screen the hero card renders a truncated address via AddressCheckphraseWithInitial (address_checkphrase_with_initial.dart:46 calls formatAddress), while the summary row now shows the full address. So the same address appears in two forms on the same screen, and the full SS58/qz… address will wrap to multiple lines in the right-aligned Flexible. The screenshot suggests this is acceptable, just confirm it's intentional rather than also updating the hero card.

Verdict

Approve with one recommended fix (the unguarded success-path setState in #1), and consider the timeout in #2. The behavior change itself is the right call.

Want me to apply the mounted guard fix (and optionally a submit timeout)?