Error handling

[ferostabio]

The front end so far does a terrible job managing errors. Not just displaying them, but even handling them. We have months-old TODOs asking how to handle errors, sometimes just printing the value and sometimes also storing it inconsistently in the store. There was an issue created for handling rpc-related issues, but we need to think this through across the app.

[brozorec]

#372 is related

[ferostabio]

@brozorec given that we need to seriously refactor all error handling code and that both snackbar and notify are bad (for different reasons), what if we use something like react-toastify?

[brozorec]

@ferostar @NikolaiYurchenko

I created a list of possible errors categorized into 3 types: "User-input", "SDK-related" and "Transaction errors". I hope it encompasses most of the errors we can have and gives a better idea of how to handle them.

You can find here a table that better visualizes the "Transaction errors": https://www.notion.so/Errors-ade48a1f62b04d059ec7be6f7b7896e3

User-input errors

These are generally errors that should be managed exclusively in the UI.

SDK errors

1. RPC failure
2. DefiLlama API failure
3. Multicall contract failure
4. On-chain query failure
5. Sdk crash

Transaction errors

1. ethers.sendTransaction - it can fail immediately, even before submitting the tx to the mempool. Ethers.js detects the tx will fail and throws an error.
   1. How to catch: try/catch
   2. Possible reasons:
      1. invalid parameters
      2. insufficient balance or allowance
      3. RPC issues
2. On-chain revert on the source chain - the tx was submitted and accepted in the mempool, however for some reason, it failed on-chain
   1. How to catch: status from the tx receipt
   2. Possible reasons:
      1. Out-of-gas (it already happened to me on Polygon)
      2. If x-chain, it could be smth related to Connext smart contracts
   3. Remedy: re-submit tx with a higher gas limit
   4. Prevent: estimate gas limit and add a 20% buffer
3. (x-chain) Low relayer fee on the destination chain (non-fatal)
   1. How to catch: call to Connext API
   2. Possible reasons:
      1. Our bumper failed to sponsor the fee
      2. Our bumper sponsored the fee, but there was a spike in the gas price on the destination chain
   3. Remedy: bump relayer fee
4. (x-chain) Slippage out of range
   1. How to catch: call to Connext API
   2. Possible reasons:
      1. Temp imbalance of Connext pool on the destination chain
      2. The user set too low slippage
   3. Remedy: set higher slippage
   4. Prevent: check slippage and warn the user when they set a lower value
5. (x-chain) Unknown issues with Connext or relayers on the destination chain
6. (x-chain) Revert on the destination chain: the tx can't be executed and the funds are transferred to a rescue contract
   1. How to catch: Check xReceived event
   2. Possible reasons:
      1. Wrong nonce
      2. Expired permission
      3. Operation too close to max LTV + a sudden change of an asset price
   3. Prevent:
      1. Don't allow the user to submit a new tx to the same vault if there's already a pending one
      2. Don't allow or warn the user when the operation too close to max LTV
   4. Remedy:
      1. Return the user’s funds
      2. Re-try operation on the destination chain