Fix for connection closed while waiting for receipt response

[gianfra-t]

157 and #160.

Following changes to the flow:

• Endpoint executeXCM prioritizes the transaction with more gas.
• Endpoint will also cache the response, such that it is compatible with the frontend possible restart and refetch of the same (id, payload). In that case to avoid saving one more extra state on the UI, the endpoint will just return again the hash. (this doesn't survive a backend restart)
• UI will now waitForTransactionReceipt instead. Continue once it is included, or error if it is not.

Recoverable errors retry

• If we do not return specifically a next phase failure in our transitions functions (like here), then the app will reload the page and restart the current phase again, until 10 minutes from the creation of the off-ramp passed.

[netlify[bot]]

✅ Deploy Preview for pendulum-pay ready!

Name	Link
🔨 Latest commit	c5a4fd7fc9379c234b59028cdc63e54245662e01
🔍 Latest deploy log	https://app.netlify.com/sites/pendulum-pay/deploys/66eb82a91cf26a00084e60ce
😎 Deploy Preview	https://deploy-preview-159--pendulum-pay.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[gianfra-t]

@pendulum-chain/devs ready for review and testing IMO. If the fix is urgent, we can later add a persistent cache on the backend (also low effort).

[gianfra-t]

I was assuming that the sendTransaction function would fail if sent twice (given that the hash is removed from the map on the contract). In that case I think it is a bit of a race condition right? If the UI reloads while sendTransaction is still waiting on the backend, then the second call to this endpoint will fail without the cache.

Again I was with the working assumption that sendTransaction throws an error when the contract reverts, and in fact when I try with some random values this is the case.

[ebma]

If we don't want to rely on the transaction cache on the webserver because it could also crash due to some unforeseen issue, we could also put the received transaction hash in the local storage to the other data we store for the offramping process. Then, when the frontend reloads, it could first check if it already received a transaction hash once and wait for the transaction receipt of that instead of hitting the endpoint again.

[gianfra-t]

@pendulum-chain/devs As I am testing the refresh solution, I realize that it is a bit bad how it looks when the page refreshes alone. Do we want to continue with this anyway?

[ebma]

Bad in what sense? Like, as a user you feel like it's buggy and the refresh is unintended? If you have a bad feeling as a user, how about we give a heads-up warning that the page is going to refresh in e.g. 10 seconds or whatever we choose? We could show this as a toast notification with the change I added in https://github.com/pendulum-chain/vortex/pull/154. Or we show a count-down in the progress-page that counts down the seconds until we perform the refresh.

[gianfra-t]

I think we should either add some UI element, or force refresh the Polkadot.js API on the background, which is the only instance we keep right? I lean for the second one to avoid doing more UI changes, but not strong opinion.

[TorstenStueber]

Some addendum to my message above. I tested to submit a transaction to the receiver contract for an id that is invalid (for example because there was already some succcessful transaction executing the XCM in the meantime).

And indeed, the sendTransaction already throws an error. This happens despite the transaction not being executed in the block yet but because the gas estimation algorithm that is happening before the transaction is submitted would already error as the transaction reverts:

Details: VM Exception while processing transaction: revert Hash invalid
Version: 2.21.3
    at [...]
  cause: EstimateGasExecutionError: An internal error was received.

I think we can just ignore this error (in absence of other bugs this just means that the funds are already on Pendulum) and instead also additionally check whether some amount of USDCaxl already arrived on the Pendulum ephemeral account and – if this is the case – switch to the next phase.

[TorstenStueber]

@gianfra-t could we maybe just get rid of the failure phase altogether? Instead of switching to that failure phase, stay in the current phase and just have a boolean hook state isFailure in, e.g., useMainProcess. This boolean state is false at start and when it is true, then show the failure screen.

This way, even when 10 minutes elapsed and we show the failure screen, one could still try to recover from the error by just reloading the page. This could address the problem that @ebma mentions above ("We also need to consider that the user might just close the during the processing and then reopen the page more than 10 minutes in the future.").

[gianfra-t]

@TorstenStueber I don't understand how that solution we would distinguish how to show or not show the failure page. Would it be time based? It is a bit confusing if the user loads the site, is shown the failure page and yet the app still is doing operations. What do you think of this idea here?

At some point we need to have some criteria (time based, count based or type of error) to show or not show the failure screen and "give up" on the process.

[TorstenStueber]

At some point we need to have some criteria (time based, count based or type of error) to show or not show the failure screen and "give up" on the process.

@gianfra-t there is no perfect solution. Either we leave it to the user to decide by showing both options Continue and Restart (as I originally proposed) or we do the Continue automatically in the background and then have to decide ourselves when to display the Restart option (e.g., the failure screen) – as we decided today.

The time based criterion is surely the easiest one. However, I somehow think that we should give the user to option to try to recover – so I figured the proposal in my last message would allow for that.

[TorstenStueber]

I took over the PR of @gianfra-t and added some more failure handling code.

I made many different tests and fixed some more issues I found.

I am adding a couple of comments to explain my changes. Here is a summary:

• I changed all Pendulum transaction to being immortal (as we discussed this week)
• the moonbeam endpoint does not wait for the transaction to receipt, instead it returns the transaction hash and the frontend waits for it
• that transaction hash is not cashed on the backend, but is stored in the frontend local storage (it is added to the offrampingState struct)
• for that reason the offrampingState local storage now also needs to change within a phase (before that it only changed at the end of each phase but now the storage changes in the middle of executeXCM, i.e., the Moonbeam xcm transaction hash is stored)
• in order to handle this properly in useMainProcess, that hook now does not only store the offrampingPhase but the complete offrampingState, so that the useEffect hook that runs advanceOfframpingState will always be executed whenever the offrampingState changes in any way and not only when the phase changes
• I changed the layout of the failure screen and allow the user to either try to continue the flow or to start over (see screenshot). In order to allow to continue the flow, I removed the failure phase completely and added a flag isFailure to the offrampingState
• I added extra checks at the beginning of every phase to check whether the phase already completed – in this case I skip the phase altogether

[TorstenStueber]

I created an extra PR to address all review comments.