Add retry mechanism for partially failed virtual card order

EresDev commented 2 months ago

In the virtual card feature, we have two parts in a single transaction to mint a virtual card.

Claim the permit by transferring the permit reward to the treasury wallet
If the step-1 is successful, order the virtual card at Reloadly

The problem is that the transaction isn't atomic because each step happens in a different system. Step-2 can fail while still leaving the permit amount in the treasury. Why would step-2 fail? There could be one of the many reasons.

virtual card suddenly becoming out of stock
any network error on user side or Reloadly side
user closing browser before the permit transaction confirmation
change in the best picked card, suddenly a better card becomes available or currently picked card becomes unavailable
RPC-handler failing to find rpc for backend to use, or if it finds one but the rpc stops working

Currently, the solution to this problem is manual. It is either a manual refund or manual resending of the card order request to /post-order with some parameters (productId, tx hash, country).

We can improve this by implementing one of the following solutions.

a manual refund can become automatic by issuing a new permit of the same amount
resend the mint request to backend to /post-order

I am inclined towards resending the mint request. One problem is that /post-order needs the transaction hash of the permit transfer to the treasury. Sometimes you will have it, and you can store it in the cookies/local storage. But sometimes you will not have it and you will have to read it either from blockchain or ask the user to manually insert the transaction hash to retry minting. I think you can read it from blockchain by looking into permit2 events

The goal of this issue is to implement a mechanism to resend the mint request or a better solution if you can think of one.

Since the best-picked virtual card can change in this duration, a better option is to rename the mint button to "Retry Mint" and let the user click first so that user can see they are ordering a different card now.

Please note that the virtual cards feature is present in beta branch at the moment. But it can move to development branch anytime. So, keep an eye on that and open a PR accordingly.

0x4007 commented 2 months ago

I think reading from local storage is ideal, then from the chain, generally speaking for these sorts of things.

whilefoo commented 2 months ago

I think this problem will be solved once we implement reward rollup and permits will be generated on demand.

For virtual cards this means when the virtual card is created, a entry in the DB will be created but if there's an error creating a virtual card, you don't write to the DB and everything is as it was. The user can retry the operation until it successfully creates a virtual card.

EresDev commented 1 month ago

I think this problem will be solved once we implement reward rollup and permits will be generated on demand.

What I see is that we are probably going to introduce the virtual card feature before the rollup feature.

zugdev commented 2 weeks ago

Can someone dm me sandbox API keys? I can't register in Reloadly since I don't have a business email.

zugdev commented 2 weeks ago

/start

ubiquity-os[bot] commented 2 weeks ago

@zugdev the deadline is at Sat, Oct 19, 4:15 AM UTC

0x4007 commented 2 weeks ago

I think you can use any email provider like proton mail

zugdev commented 2 weeks ago

It's https://www.reloadly.com/ right?

0x4007 commented 2 weeks ago

Im sure that you can use your own domain's email then. Setting up email forwarding is simple on cloudflare and google domains.

harshmittal1750 commented 1 week ago

/start

ubiquity-os[bot] commented 1 week ago

! This issue is already assigned. Please choose another unassigned task.

0x4007 commented 1 week ago

@gentlementlegen disqualify check

gentlementlegen commented 1 week ago

You can always check the logs: https://github.com/ubiquity-os-marketplace/daemon-disqualifier/actions/runs/11548428245/job/32139825686

0x4007 commented 1 week ago

Can you fix this signature thing across all of our plugins?

gentlementlegen commented 1 week ago

@whilefoo pointed out that it could potentially be because of the use of both the beta and the release that would require different signatures.

0x4007 commented 1 week ago

Do you guys have a solution in mind?

gentlementlegen commented 1 week ago

If that is indeed the reason we need to make proper use of environments for the plugins and secrets. I need to check if that's the root cause.

whilefoo commented 1 week ago

We could modify the SDK to verify the signature for either prod or dev bot

ubiquity / pay.ubq.fi

Add retry mechanism for partially failed virtual card order #291