Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Restore: a seller restored at waiting-payment cannot recover the hold invoice

Open
  • Is something wrong?
#549 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
dart, rust
Domain
backend-api-design

Research direction

Start by reading mostrod's util.rs take path and its Action::PayInvoice send, then trace how Action::Orders and RestoreSession rebuild a waiting-payment trade. The issue leaves the recovery approach open, so first determine which option should be pursued and how the app can request or receive the invoice. Done means a restored seller can recover the hold invoice when the relay no longer has the message; the issue names no tests.

Written by the indexing model from the issue text.

Description

area: protocol enhancement priority: low

Summary

After a restore, a trade rebuilt from the daemon's own record (#546) carries no hold invoice. A seller restored at waiting-payment sees the trade but not the bolt11 to pay. If the relays no longer hold the daemon's pay-invoice message, nothing brings the invoice back, and the daemon cannot resend it today.

Low priority: the window is short (see How often). Filed so the gap is tracked rather than lost, now that #216 is closed.

What happens today

  • The bolt11 reaches the client once, in pay-invoice, when the order is taken (mostrod util.rs, the Action::PayInvoice send in the take path).
  • mostrod does not store it afterwards. The orders table keeps hash and preimage, not the payment request; the only payment_request column is on bonds.
  • A restore rebuilds the row in one of two ways:
    • by replaying the daemon's kind-14 messages, which works when the relay still holds pay-invoice;
    • from Action::Orders (#546), whose SmallOrder carries no hold invoice. mostrod also strips buyer_invoice from that reply on purpose.

How often

hold_invoice_expiration_window = 300 by default, so the seller has 5 minutes to pay before the scheduler acts. The gap needs all of the following at once:

  1. a seller restores (new device or re-import) inside those 5 minutes;
  2. the relays have lost that one pay-invoice message;
  3. and the trade is still waiting on that payment.

That is rare, but when it happens the seller cannot pay from the app until the order expires.

The buyer side (waiting-buyer-invoice) is different. The buyer sends an invoice, and the amount is in the rebuilt order, so nothing from the daemon is missing. Worth confirming in the UI that a restored buyer is actually offered the add-invoice step.

Options

  1. The daemon re-sends pay-invoice on request. It can recover the bolt11 from its Lightning node by the stored hash (e.g. an LND invoice lookup returns the payment request). This needs a way to ask: a new action, or answering RestoreSession / Orders for a waiting-payment seller by re-sending the message.
  2. Include the payment request in the restore reply for a seller at waiting-payment. mostrod would first have to start persisting it at take time.
  3. Do nothing, and let the order expire and return to the book. The seller can take or republish afterwards. This is the current behaviour.

Option 1 changes the least: it reuses the existing message the client already handles.

Context

Closing #216 (authoritative RestoreData snapshot). Its goals are otherwise met by composition: the peer trade pubkey (#544, mostro#966), role and order fields from Action::Orders (#546), and the solver pubkey, which was already in RestoredDisputesInfo. This is the one piece of "the order fields needed to build TradeInfo" that no current path recovers. Part of #142.

Dominant language
Dart
Stars
11
Forks
9
Avg merge
13h 4m
Merged PRs (30d)
259

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MostroP2P/app

All issues in MostroP2P/app

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.