Add-invoice screen stays on "Sent, waiting for the node" after a late acceptance on a sell order
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
Research direction
Start in lib/features/order/screens/add_lightning_invoice_screen.dart, especially invoiceStepIsOver and _listenForProgress; check how the screen reacts when tradeStatusProvider changes after a timed-out submission. Add a widget test that drives the status from waitingBuyerInvoice to waitingPayment; done means the screen navigates to /trade_detail/:orderId after the late acceptance.
Written by the indexing model from the issue text.
Description
What happens
When the buyer sends their invoice and mostrod takes more than 10 s to answer, the add-invoice screen (/add_invoice/:orderId) shows "Sent. The node has not answered yet; we will take you to the trade as soon as it does" (invoice.awaiting). When the daemon then accepts the invoice on a sell order, the screen does not move: it keeps that note, even though the node already answered and the trade moved on. The buyer only leaves when the seller pays the hold invoice and the trade turns active, or when the trade is cancelled. Until then nothing tells them the invoice was accepted.
Measured
Local regtest mostrod, app on Linux desktop as the buyer (taker) of a sell order, invoice sent a few seconds after the step's countdown reached 00:00 (UTC, app log):
23:06:17Z orders: add_invoice published for order=b22acbb1 … — waiting for daemon
23:06:27Z orders: add_invoice: no daemon verdict within 10s … — a late reply still applies
23:06:38Z daemon-msg: action=WaitingSellerToPay order_id=Some(b22acbb1-…)
23:06:38Z orders: status order=b22acbb1 →WaitingPayment src=kind14/WaitingSellerToPay
The screen still read "Sent. The node has not answered yet…" afterwards, until the trade was cancelled because the seller (mostro-cli) never paid. An earlier run reproduced it the same way (reply after 20 s). On that node, replies of 20 s or more were common.
Why
_listenForProgress (lib/features/order/screens/add_lightning_invoice_screen.dart:697) is what takes the screen to the trade after a late acceptance (#615). It leaves only when invoiceStepIsOver(status) (:46) is true, and that list is active, fiatSent, dispute, success, settledByAdmin, completedByAdmin.
Which status follows an accepted invoice depends on the order side:
| Order | Who adds the invoice | Status after the daemon accepts it |
|---|---|---|
| Buy | the buyer, as maker, after the seller paid | active → the screen leaves ✔ |
| Sell | the buyer, as taker, before the seller pays | waiting-payment → the screen stays ✘ |
On time (under 10 s) the submit handler itself navigates (:509), so the bug only shows when the reply is late. a22f7285 introduced the list with active in mind.
Can the buyer be on this screen in waiting-payment for another reason?
No. Every live entry point opens it only in waiting-buyer-invoice: the trade screen's button and the My Trades verb (TradePrimaryAction.addInvoice exists only for the buyer in waitingInvoice), the take (take_order_screen.dart), the bond screen (pay_bond_invoice_screen.dart) and trade_action_listener.dart. mostrod only moves the trade from waiting-buyer-invoice to waiting-payment by accepting the invoice. So waitingPayment on this screen always means the invoice was accepted.
were added in cc298d65), so that branch is unreachable.
Proposed fix
Count waitingPayment as over in invoiceStepIsOver, so a late acceptance on a sell order takes the buyer to the trade screen like one on a buy order does. A widget test can drive tradeStatusProvider from waitingBuyerInvoice to waitingPayment after a submission that timed out and assert that the screen goes to /trade_detail/:orderId; that test fails on main today.
v1
MostroP2P/mobile leaves the add-invoice screen right after publishing the invoice (context.go('/') after sendInvoice, lib/features/order/screens/add_lightning_invoice_screen.dart:168-247), without waiting for the daemon's answer.
Related cleanup (not part of the fix)
NotificationType.orderUpdate, orderTaken and invoiceRequest, their factories and their routing in notifications_screen.dart are dead code and could be removed.
- Dominant language
- Dart
- Stars
- 11
- Forks
- 9
- Avg merge
- 18h 24m
- Merged PRs (30d)
- 193
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MostroP2P/app
-
area: rust-core bug priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
area: ui
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
Similar issues
-
good first issue help wanted translation
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
blankframe-tech/ThrottleIQ#23 ·
Maintainers usually reply within 5 days
-
good first issue mobile P0 size:S
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
trufi-association/trufi-core#1024 ·
Maintainers usually reply within 14 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
-
@apps/catalog enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
ymm-oss/flutter-mobile-project-template#699 ·
Maintainers usually reply within 15 days