Resolve delay in recognizing confirmed transactions

[314159265359879]

Here transaction in microblock

Yet on wallet shown as available

trying to sign a transaction will fail because the balance isn't actually available:

This is happening on mainnet too:
https://discord.com/channels/621759717756370964/745197302255321108/1044462352642363412

Additionally when the transaction was confirmed in an anchorblock. I tried to send the transaction again from the btc.us testenvironment. And it would still show "insufficient" balance error on the confirm screen. I was only able to resolve this after logging out from the dapp and then logging in again, then the confirm screen still blinked "insufficient balance" for a split second before showing the expected:

[314159265359879]

Steps to reproduce on testnet:

1. create new account
2. get funds from faucet via explorer sandbox
3. login on https://btc-website.tintashlabs.com/ (when faucet transaction is in microblock, before confirmed in anchor)
4. Try to register a domain
5. --> try to sign first transaction
6. see error

[314159265359879]

I would expect the balance not to show as available as long as the transaction is only in a microblock and not anchored yet. This is adding to the confusion.

After being anchored I would expect not to see any "insufficient balance" errors. I am not sure why I need to relog on the dapp.

[markmhendrickson]

I would expect the balance not to show as available as long as the transaction is only in a microblock and not anchored yet. This is adding to the confusion.

I agree. It's unexpected and incorrect to include microblock amounts in the app nav balance here. We should update to show just anchored amounts.

After being anchored I would expect not to see any "insufficient balance" errors. I am not sure why I need to relog on the dapp.

To be clear here, you had to sign out of the dapp itself and re-authenticate entirely? Not just close the transaction signing window and reopen it with the app-based action?

I can't imagine why re-authenticating the app should affect the behavior here, so I suspect it may have been simply a question of timing in that the wallet hadn't yet recognized the anchor block.

Mind trying to recreate this problem but waiting 1 minute after the transaction is included in an anchor block to see if the wallet recognizes it?

then the confirm screen still blinked "insufficient balance" for a split second before showing the expected:

This sounds like a visual bug of sorts we should also iron out, if this error is showing incorrectly during load for accounts that do have sufficient balances.

[314159265359879]

To be clear here, you had to sign out of the dapp itself and re-authenticate entirely? Not just close the transaction signing window and reopen it with the app-based action?

That is correct, re-authenticating.

I can't imagine why re-authenticating the app should affect the behavior here, so I suspect it may have been simply a question of timing in that the wallet hadn't yet recognized the anchor block.

Mind trying to recreate this problem but waiting 1 minute after the transaction is included in an anchor block to see if the wallet recognizes it?

Yes I can recheck that. Also waiting to hear back from another user.

[314159265359879]

@markmhx
This is two minutes after the anchor block confirmation
(after 6 minutes it is fine without re-authenticating, see further down but wallet balance updating so slowly is a problem)

oddly the wallet shows:

with this in the activities tab (upto 5 minutes after the anchor block):

This is what Bruffstar was reporting earlier in the wallet channel on Discord.

This is 6 minutes after the anchor block... all good (no re-authentication needed)

(6 minutes is not normal, different issue most likely something with API service?)

[markmhendrickson]

Are you checking the explorer specifically for confirmation and it does show as confirmed there before the wallet? If so, that might suggest it's a wallet-specific problem because the explorer and wallet are using the same API.

However, it's also possible they're using different endpoints with different behaviors here.

I'm going to relabel this as P2 at least until we get reports that these delays are widespread. Mind splitting the problem with displaying microblock effects in the app nav balance into a separate issue for tracking there as a P2?