Handle errors when sending tokens within Aurora to NEAR

[mfornet]

Currently the way exit precompiles work, is that it:

1. verifies the amount of tokens is owned by the user inside Aurora
2. burns those tokens
3. schedule a cross contract call to mint/create withdrawal event on NEAR

Currently if step 3) fails for some reason, tokens are burnt within aurora, and not minted on NEAR, so basically they are lost. We need to handle failures on step 3. This is, we schedule yet another call after the exit call where we see if the tx succeeded or not, in case it didn't succeed funds should be refunded.

This was first detected on this tx. Where ft_transfer failed because receiver account was not registered in the NEP-141 tokens. Currently this tokens are being held by aurora account, but they were not refunded to the user.

[joshuajbouw]

That is rather unfortunate. We will look into this.

[sept-en]

Update on this: the tokens were manually refunded to the user on this tx

[mrLSD]

This is, we schedule yet another call after the exit call where we see if the tx succeeded or not, in case it didn't succeed funds should be refunded.

Seems we can't do that. The main reason promises are async. Also, we can't analyze TX inside aurora contract. We should have some mechanism outside aurora contract that will check exit precompiles outcome and fire new call for a refund if something wrong.

Obvious solutions:

1. less reliable but simple - we can do it via front-end action
2. We can implement and run it as some service that can analyze exit precompiles incidents and fire-related actions to solve it.

@mfornet, @joshuajbouw let's choose the best solution for that.

[birchmd]

@mrLSD I think you should be able to attach a callback to the promise (using the then API). That callback should check for success of the previous call and revert the transfer to the precompile on failure (it can do this because it should happen within the Aurora engine contract itself)

I.e. you should be able to do was @mfornet suggested in the issue description using a callback

(Sorry I did not intend to close this issue with my comment, so I reoopened it)

[mrLSD]

I investigated that, and still have questions.

So, the callback function for failing case for that promise looks really dangerous. It seems possible bugs, which are difficult to catch.

Anyway, we have promise schedule:

aurora-engine/src/precompiles/native.rs

Line 167 in 3eace8c

let promise: Vec<u8> = PromiseCreateArgs {

So I'll implement a dependent promise burn from aurora account and mint to the receiver account.

But do we really clear that the approach doesn't have pitfalls?
@sept-en @joshuajbouw

[birchmd]

So I'll implement a dependent promise burn from aurora account and mint to the receiver account.

No, this is not what you should do. The transfer that needs to be reverted in the the engine itself. You need to transfer the tokens back from the precompile address to the user's address in the engine. The NEP-141 balances do not need to be changed because this flow only triggers when the NEP-141 transaction was unsuccessful.

So, the callback function for failing case for that promise looks really dangerous. It seems possible bugs, which are difficult to catch.

I'm not sure what you are worried about. Could you elaborate more about the danger here?

[birchmd]

@mfornet Could you take a look at #284 (comment) ? Have you thought about the case where the exit precompile was invoked as part of a larger transaction?

[mfornet]

@birchmd answered on this comment: #284 (comment)

[birchmd]

@mfornet , I've replied #284 (comment)