Skip to content

Add section about automated retries for payments in README #2136

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Add section about automated retries for payments in README #2136

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -187,6 +187,7 @@ After `nlp-setup` is done, restart your containers to enable semantic search:
- [Stack](#stack)
- [Services](#services)
- [Wallet transaction safety](#wallet-transaction-safety)
- [Automated payment retries](#automated-payment-retries)
- [Need help?](#need-help)
- [Responsible Disclosure](#responsible-disclosure)
- [License](#license)
Expand Down Expand Up @@ -479,6 +480,18 @@ To ensure stackers balances are kept sane, some wallet updates are run in [seria

<br>

## Automated payment retries

Every payment for `ITEM_CREATE`, `ZAP`, `DOWN_ZAP`, `POLL_VOTE`, and `BOOST` is attempted three times (first attempt + two retries). We wait 1 minute and up to 1 hour before we return a failed invoice via the `failedInvoices` query to a client to retry. During each retry, we increment the `paymentAttempt` column of the new invoice and add a link to the previous invoice in `predecessorId`.

For p2p zaps, we have additional logic to try every sender and receiver wallet. This means that for p2p zaps, we can create multiple invoices per attempt.

We fallback to the next sender wallet if paying the wrapped invoice failed (unless the payment failed because the invoice expired or was canceled). We do this via a loop over all sender wallets on the client and checking if the payment error is not an instance of `WalletReceiverError`. We will retry with the same sender wallet in that case.

On any wallet payment error (= payment did not fail because the invoice expired or was canceled), we cancel the invoice and ask the server to create a new one for us. The server is able to know if it should fallback to the next receiver wallet or not because it knows if the wrapped invoice we're retrying failed because the wrapped invoice was never paid (sender error) or if forwarding failed (receiver error).

<br>

# Need help?
Open a [discussion](http://github.com/stackernews/stacker.news/discussions) or [issue](http://github.com/stackernews/stacker.news/issues/new) or [email us](mailto:[email protected]) or request joining the [dev chat](#dev-chat).

Expand Down