"Not enough native balance, token ETH, chain id <chainId>" Toast shown when insufficient ETH to cover the fee on send page

[VolodLytvynenko]

Follow up for https://github.com/status-im/status-mobile/pull/21235

Steps:

1. Go to the transaction confirmation page.
2. Enter the valid amount of ERC-20 requiring ETH to cover the fee.
3. Ensure the ETH balance is insufficient to cover the transaction fee.

Actual Result:

A toast message is displayed: "Not enough native balance, token ETH, chain id <chainId>."

Expected Result:

The toast message is not shown

Devices:

• Pixel 7a, Android 13
• iPhone 11 Pro Max, IOS 17

[clauxx]

@VolodLytvynenko @shivekkhurana so here we should just hide the toast for this error? What should we do in case of other router errors i.e. which ones we should show and which ones ignore? e.g.

"not enough token balance, token: %s, chainId: %d"                                   
"not enough native balance, token: %s, chainId: %d"                                  
"native token not found"                                                             
"token not found"                                                                    
"no best route found"                                                               
"cannot check balance"                                                               
"bonder fee greater than estimated received, a higher amount is needed to cover fees"
"no positive balance"                                                                

[VolodLytvynenko]

@xAlisher, could you take a look at this question? Perhaps some additional validation should be added in the Figma.

Currently, we only have a Figma design for: 'Not enough native balance, token: %s, chainId: %d' — Figma link.

I believe the case 'No positive balance' is impossible to reach on the client.

For other cases:

'Not enough token balance, token: %s, chainId: %d' 'Native token not found' 'Token not found' 'No best route found' 'Cannot check balance' 'Bonder fee greater than estimated received, a higher amount is needed to cover fees'

should we just show something went wrong as described here ?

[VolodLytvynenko]

@clauxx Could you please provide a more detailed explanation of the validations and correct me if I'm misunderstanding anything:

1. 'Native token not found' – Does this occur if the user selects a token that is not supported by the network and tries to send it using that network? if so, this feature is handled in our app

2. 'Token not found' – (Could you clarify in which cases it can occur?)

3. 'No best route found' – I believe in this case we should attempt to find another available network. (In my opinion, we should leave this toast If this happens)

4. 'Cannot check balance' – (Could you clarify in which cases it can occur?)

5. 'Bonder fee greater than estimated received, a higher amount is needed to cover fees' – This occurs when the transaction amount is less than the required fee to cover the transaction. For example, to send 0.000001 ETH from L1 to L2, the user would need to pay 0.000002 ETH in fees. I believe we should have additional design for this case

cc: @xAlisher

[clauxx]

@clauxx Could you please provide a more detailed explanation of the validations and correct me if I'm misunderstanding anything:

1. 'Native token not found' – Does this occur if the user selects a token that is not supported by the network and tries to send it using that network? if so, this feature is handled in our app

2. 'Token not found' – (Could you clarify in which cases it can occur?)

3. 'No best route found' – I believe in this case we should attempt to find another available network. (In my opinion, we should leave this toast If this happens)

4. 'Cannot check balance' – (Could you clarify in which cases it can occur?)

5. 'Bonder fee greater than estimated received, a higher amount is needed to cover fees' – This occurs when the transaction amount is less than the required fee to cover the transaction. For example, to send 0.000001 ETH from L1 to L2, the user would need to pay 0.000002 ETH in fees. I believe we should have additional design for this case

cc: @xAlisher

1. I've been getting this error randomly sometimes and there's already an issue for it
2. not sure about this one either
3. sure, can keep it
4. the error is returned here, but it looks like it will never be returned, so no idea why it's even there
5. :+1:

[clauxx]

should we just show something went wrong as described here ?

@VolodLytvynenko @xAlisher yeah I think this would be best. I don't see any toasts error toast in the design, we just show "No routes found" and "Try again" button, so I think it would make sense to not show error toasts in the send modal at all. WDYT?

[churik]

@VolodLytvynenko @xAlisher @clauxx I think it is not wrong that we show this error, the wording is not best, but it is a way clearer than "Something went wrong"

I'd suggest to postpone the handling of toast error, wdyt?

[VolodLytvynenko]

@VolodLytvynenko @xAlisher @clauxx I think it is not wrong that we show this error, the wording is not best, but it is a way clearer than "Something went wrong"

I'd suggest to postpone the handling of toast error, wdyt?

Agree with @churik . A few toast with errors will disappear after implementing new sending flow

[clauxx]

sounds good to me :+1:

[VolodLytvynenko]

still valid. Not related to new rpc from https://github.com/status-im/status-mobile/pull/21378

[churik]

removed bug, as it is understandable, but doesn't match the design

[VolodLytvynenko]

@shivekkhurana I suggest moving this issue to later milestones. We still need the toasts for debugging the router problem if something goes wrong. They aren't user-friendly, but it's better to keep them for now until the new send flow is ready. WDYT?

[VolodLytvynenko]

This issue is resolved in the new simplification flow https://github.com/status-im/status-mobile/pull/21595