churik commented 3 months ago

Bug Report

Problem

Should be tracked separately, as we should find a way to show user the last available balance if they are offline or they hit request rate limit

Expected behavior

can see your last balance

Actual behavior

After pull-to-refresh all the ERC-20/ETH are not shown anymore, and the wallet looks empty:

https://github.com/user-attachments/assets/49e5cfcf-aa38-4b85-9d40-859e936a396a

Reproduction

Open wallet with funds
Switch off internet
Pull-to-refresh

Additional Information

Status version: 2.30
Operating System: Android, iOS
logs: logs (111).zip

VolodLytvynenko commented 2 months ago

The issue is still reproducible. Balances displayed as 0 after network connection loss and wallet refresh

Steps to Reproduce:

Go to wallet
Disconnect the network connection.
Refresh the wallet page.
Observe the token balances.

Actual Result:

All token balances are displayed as 0 after the wallet is refreshed while the network is disconnected.

https://github.com/user-attachments/assets/ee3d605e-9113-4691-a3cb-fbf6f408c8c8

Logs:

logs (4).zip

ENV:

release 2.30. build 20240812160215

churik commented 2 months ago

сс @alaibe

shivekkhurana commented 2 months ago

The Go side PR was merged to develop. Can you check if the fix was applied ? @churik @pavloburykh

https://github.com/status-im/status-go/pull/5704

pavloburykh commented 2 months ago

The Go side PR was merged to develop. Can you check if the fix was applied ? @churik @pavloburykh

status-im/status-go#5704

@shivekkhurana are you sure it is ready for test? We checked that commit in https://github.com/status-im/status-mobile/pull/21039 and it didn't work. As far as I know @cammellos and Anthony are working on the fix for mobile. I see there is some other go PR which is open https://github.com/status-im/status-go/pull/5712

shivekkhurana commented 2 months ago

5712 was just opened. I thought 5704 would fix it.

cammellos commented 2 months ago

1) We are making historical request to arbitrum one (non archival?) 42161, that causes the circuit to open and the "chain goes down" (it's a bit of a guess on the historical requests)

2)

WARN [08-15|12:15:10.468|github.com/status-im/status-go/rpc/chain/client.go:979]                                                      Error in chain call                      error="prod.api.status.im.error: context canceled" chain-id=1
WARN [08-15|12:15:10.468|github.com/status-im/status-go/rpc/chain/client.go:979]                                                      Error in chain call                      error="prod.api.status.im.error: Post \"https://prod.api.status.im/grove/ethereum/mainnet/\": context canceled" chain-id=1
WARN [08-15|12:15:10.468|github.com/status-im/status-go/rpc/chain/client.go:979]                                                      Error in chain call                      error="prod.api.status.im.error: Post \"https://prod.api.status.im/grove/ethereum/mainnet/\": context canceled" chain-id=1

Requests fails in batch, very quickly, that might indicate we are hitting the limit, I can't remember, but some providers just drop the request if you hit them too hard

3)

WARN [08-15|12:15:36.982|github.com/status-im/status-go/rpc/chain/client.go:979]                                                                   Error in chain call                      error="prod.api.status.im.error: failed with 50145786 gas: insufficient funds for gas * price + value: address 0x527d22094166ad33e7523D2CBCa287798e149C7F have 68251537427723 want 100000000000000" chain-id=42161

This looks like an error that should not be triggering a chain id is down 4) WARN [08-15|12:15:45.814|github.com/status-im/status-go/rpc/chain/client.go:979] Error in chain call error="prod.api.status.im.error: execution reverted: L2_AMM_W: Bonder fee cannot exceed amount" chain-id=42161 Same as above

5) WARN [08-15|12:15:53.013|github.com/status-im/status-go/rpc/chain/client.go:979] Error in chain call error="prod.api.status.im.error: not found" chain-id=1 same

6) WARN [08-15|12:27:05.401|github.com/status-im/status-go/rpc/chain/client.go:979] Error in chain call error="prod.api.status.im.error: hystrix: circuit open, prod.api.status.im.error: hystrix: circuit open, optimism-archival.rpc.grove.city.error: json: cannot unmarshal string into Go struct field jsonrpcMessage.error of type rpc.jsonError, optimism-mainnet.infura.io.error: Post \"https://optimism-mainnet.infura.io/v3/c1f79f33854e462fb2b9fbc4df1a5d62\": context canceled" chain-id=10 That looks like some malformed request?

those are in <@746044567681237092> logs the thing that trigger the "network is down popup". So I would probably (though not an expert in the code): 1) Understand why 1) is happening, looks like a misunderstanding or misconfiguration 2) In 2) These probably should be relaxed, there's a flurry of the same error coming through, seems the lowest priority of all of them 3) Number 3/4/5/6 should not be considered "chain is down" errors 4) 6 looks like an application error, we should probably identify and fix

Update on my side: (I will loop back those on issues and copy over what I found).

Currently I have 0 cached balances, that might be for historical reasons and might be fixed, but I would watch out for that fix.
I have made so that pull to refresh always fetches fresh data, max call per 10s, that's because this is the user expectation (discussed with <@745755173174902806> )
analysis on errors from providers https://discord.com/channels/1210237582470807632/1217172571917647932/1273627208950218763
Another thing that I noticed, is that the circuit breaker is per host/port combination. That worked well before, but now if any provider behind the proxy returns an error that would break the circuit, the whole proxy is considered down. The logic should be more elaborate, and we should be able to distinguish between: 1) A provider is down 2) The proxy is down. If the proxy is down, the behavior above is correct, but otherwise, we just break all the circuits because one provider returned an error condition
another error error="prod.api.status.im.error: {\"request_id\":\"d271a0fed2\", \"details\":\"error selecting node\"}, prod.api.status.im.e that breaks the circuit and maybe it should not? though not sure what it means.
offline requests make the circuit break, we should not query if we are offline, otherwise the app I believe it thinks everything is down

cammellos commented 2 months ago

The same applies for rpc rate limiter, is per host, which kind of makes sense, but i am not sure that's expected, so I think i will start by making it per "provider"

ilmotta commented 2 months ago

@cammellos @churik based on the reproduction steps this issue is no longer valid, because balances are kept intact when the device goes offline. Or is there something from this issue we need to take care of in a new issue?