Clicking on 'pending' does not prevent double payments

[ekzyis]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When an item is created and the wallet is not immediately able to pay it, we show pending next to it.

When this is clicked, we show a QR code for the same invoice we're currently still attempting to pay in the background via the attached wallets.

This means it is possible that the invoice can get paid twice.

Screenshots

No response

Steps To Reproduce

1. Attach wallet that doesn't respond
2. Create item
3. Click on pending
4. Check console: we're still polling for the same invoice in the background

Expected behavior

Clicking on pending cancels the previous invoice and shows a new invoice.

Logs

No response

Device information

No response

Additional context

No response

[huumn]

Clicking on pending cancels the previous invoice and shows a new invoice.

I don't think this is the expected behavior in all cases. Sometimes I click on pending to see how long the attached wallet has been attempting payment.

I agree with the general problem though. The current UI/UX allows double payments and it shouldn't.

[ekzyis]

Copying my comment in #1674 that I should probably have added here:

As discussed in our meeting, I will not continue with this PR since it's not a big problem that we're still trying to pay with attached wallets in the background while we show the QR code. Receiver fallbacks (#1494) are more important currently.

If I remember correctly, it was also mentioned that the UX is not clear that clicking on pending cancels the payment in the background just to show a new invoice in the QR code. If you then close the QR code again, the wallets no longer attempt the payment in the background but only when you click on retry payment again, at which point it goes back to pending.

I personally think these UI state transitions (retry payment -> pending -> QR code -> ...) can be a good UX. But because implementing the necessary cache updates to make this work well is kind of complicated/messy, we should rethink how we do these cache updates before we attempt any such thing.

However, there's an issue with this that already exists and this PR doesn't fix: pending does not necessarily mean the wallets are attempting to pay since if you refresh the page, any payments attempts no longer happen but it still shows pending.

Fixing this would probably be the better first step to improve the user-facing code around retries.

-- #1674 (comment)

Sometimes I click on pending to see how long the attached wallet has been attempting payment.

Oh, interesting. If it's a fresh page load, don't you get the same information from the relative time? For example, 1m means here that the payment is pending since a minute:

[huumn]

That number doesn't update if I haven't navigated back to it. I'd probably still open anyway because I'd have to know/trust those numbers were correlated (and certainly the average stacker wouldn't know that).

[ekzyis]

The current UI/UX allows double payments and it shouldn't.

Maybe we should only stop attempting the wallets in the background but keep the same invoice. Once the QR code is closed, we can continue to attempt payment with the wallets again.

[huumn]

There's no way to stop the wallets in the background generically, e.g. after I've send off an NWC pay_invoice request or whatever it's called.

[ekzyis]

Ahh, right