While sending tokens from Near to Ethereum, in the second step (unlocking the tokens on Ethereum side) we should use latest height reported by NearOnEthClient to build the proof. Probably the problem right now is that the current height to use is computed once, and stored locally in the browser.
As a reference, in this lines we should be using latest height, and proof accordingly to the selected height. The should be recomputed at some point prior this moment, and my guess is that the best way to do it is to actually compute in the moment the user hit the withdraw transfer, without persisting this info anywhere with the intention of re-using in case of failure.
This solves the following issue. After upgrading the Client on Ethereum, the new contract didn't have any of the old blocks from NEAR, but only blocks after it was deployed. Some users, started the withdraw transaction before the upgrade, but didn't finish it before the contract was upgraded. They are trying to submit the unlocking transaction using a proof of inclusion in a block that can't be used anymore by the client.
mfornet
commented
3 years ago
While sending tokens from Near to Ethereum, in the second step (unlocking the tokens on Ethereum side) we should use latest height reported by NearOnEthClient to build the proof. Probably the problem right now is that the current height to use is computed once, and stored locally in the browser.
As a reference, in this lines we should be using latest height, and proof accordingly to the selected height. The should be recomputed at some point prior this moment, and my guess is that the best way to do it is to actually compute in the moment the user hit the withdraw transfer, without persisting this info anywhere with the intention of re-using in case of failure.
This solves the following issue. After upgrading the Client on Ethereum, the new contract didn't have any of the old blocks from NEAR, but only blocks after it was deployed. Some users, started the withdraw transaction before the upgrade, but didn't finish it before the contract was upgraded. They are trying to submit the unlocking transaction using a proof of inclusion in a block that can't be used anymore by the client.