The maker's waiting step has no countdown, although mostrod announces when it starts
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 85/100
Research direction
The change is needed in rust/src/api/orders.rs, in the generic order status handling arm. Add calls to record_invoice_step_start for the WaitingSellerToPay and WaitingBuyerInvoice statuses, following the existing pattern used for AddInvoice and PayInvoice. Align with modifications from related PR #574 that updates record_invoice_step_start and adds clear_maker_step_start if that PR is merged.
Written by the indexing model from the issue text.
Description
Since #564, Trade detail shows no countdown to a maker waiting on the counterparty. The PR explains why: a maker "cannot tell when the step ends". That is not a protocol limit. mostrod tells the maker when the step starts; the app receives that message and does not record it. I ran the case of a buyer waiting for the seller to pay; a seller waiting for the buyer's invoice goes through the same code, but I did not run it.
What mostrod sends
Local regtest, mostrod ff47fd0, expiration_seconds = 180. Buy order 0ceb90c8 created from the app (maker), taken with mostro-cli takebuy (seller). mostrod log, UTC:
| Time | Event |
|---|---|
| 17:43:25.749 | order moves to waiting-payment (the take) |
| 17:43:26.074 | sends waiting-seller-to-pay to the maker's trade key (trade_index 9, the app) |
| 17:47:24.237 | Republishing order … taker (seller) did not pay the hold invoice in time, order back to pending |
Sending message ... with payload: "{\"order\":{\"version\":2,\"request_id\":12843372056757626003,\"trade_index\":9,\"id\":\"0ceb90c8-16bb-434c-ac83-8f9ded24c6b8\",\"action\":\"waiting-seller-to-pay\",\"payload\":null}}"
The payload is null, but the message's own timestamp is the step start, 0.3 s after the take.
Where the app drops it
rust/src/api/orders.rs records a step start only in the AddInvoice and PayInvoice arms (record_invoice_step_start). WaitingSellerToPay and WaitingBuyerInvoice fall into the generic status arm, which updates the status and records nothing. With no recorded start, invoiceDeadlineProvider returns null for a maker (trade.order.isMine), and Trade detail draws no countdown.
Proposed change
In the generic status arm, call record_invoice_step_start for WaitingSellerToPay and WaitingBuyerInvoice, the same way AddInvoice and PayInvoice do. invoiceDeadlineProvider already reads a recorded start before the isMine check, so the Dart side should need no change. Not verified: I read this path; I did not run it.
Related
- #564: the PR that decided to draw nothing without a start. Drawing nothing is right when the start is unknown; this issue is about making it known.
- #569: in the run above mostrod acted 58 s after the window ended (238 s after the take, window 180 s). A maker countdown has the same issue #569 describes: at 00:00 it must wait for mostrod, not announce a cancellation.
- #574: changes
record_invoice_step_start(adds the trade index) and clears the maker's step start when the order returns to the book (clear_maker_step_start). The change proposed here should build on it.
- Dominant language
- Dart
- Stars
- 11
- Forks
- 9
- Avg merge
- 11h 18m
- Merged PRs (30d)
- 246
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
-
Add-invoice screen stays on "Sent, waiting for the node" after a late acceptance on a sell orderOpenbug priority: medium
Difficulty 2/5 1-3 hours 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 72/100
MostroP2P/app#341 · 1 comment ·
Maintainers usually reply within 1 day
-
CONTRIBUTING.md: Protocol/Transport section still says peer and dispute chat use NIP-59 gift wrapOpen
Difficulty 1/5 Under an hour Newbie friendliness 90/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
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
OpenBikeControl/bikecontrol#404 · 1 comment ·
Maintainers usually reply within 1 day
-
[Bug]: Language picker in Settings doesn't scroll; last languages overlap the buttonsPossibly taken A pull request linked to this issue is open or already merged. Openbacklog:medium bug localization
Difficulty 1/5 Under an hour Newbie friendliness 90/100
simonoppowa/OpenNutriTracker#1331 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
MunichWays/munich-ways-app#248 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
lollipopkit/flutter_server_box#1659 · 1 comment · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100