search

aurora-is-near / rainbow-bridge-client

Monorepo containing Aurora-maintained libraries for using the Rainbow Bridge
https://github.com/near/rainbow-bridge-client/tree/main/packages/client#readme
MIT License
25 stars 7 forks source link

fix: don't checkStatus if wrong eth network #4

Closed paouvrard closed 3 years ago

paouvrard commented 3 years ago

Checking the status of a transfer must be done with the same Ethereum network for which that transfer was made i.e matching the bridge. Skip to the next loop until the provider chain id matches the expected chain id.

paouvrard commented 3 years ago

I don't think that we need separate databases for accounts because the minter/unlocker doesn't need to be the recipient of a transfer, so this flexibility is good. I only see the edgecase where a user changes eth accounts between an approve and a lock: metamask will show an always failing tx before it is broadcasted so the user can check the sender account on the transfer information. Bridge instances will be separated by domain name, so each app can be identical which makes the app logic simpler as it doesn't require knowledge of different bridges.

paouvrard commented 3 years ago

I suggest we continue the discussion here https://github.com/near/rainbow-bridge-client/issues/6 as there are many things and UX to consider for supporting multiple bridges from the same dapp UI. This PR was improved to avoid false positive checkStatus errors which might happen when a transfer is in progress and the user changes eth network. Stopping checkStatusAll or checking the eth network at the beginning of a checkStatusAll call would not solve the issue as the eth network may still be changed. The new fix will skip the checkSync / checkUnlock / checkApprove / checkLock if the eth network is incorrect right after the web3 object is created.