fix(orders): handle inbound add-invoice in the kind-14 ingest - #288
Conversation
- New AddInvoice arm: the daemon's invoice request to a maker buyer was falling into the catch-all, the trade never left WaitingPayment and died by timeout. - Persists status and calculated sats to the order book and trade DB, keyed by the message's order id (it arrives with trade_index=None). - The book gets the amount too: the add-invoice screen polls it and refuses an LN address without a known amount. - The follow-up AddInvoice with a Peer payload (reputation) is ignored. - status_for_action maps AddInvoice → WaitingBuyerInvoice for payload-less messages; add_invoice_sync helper with unit tests.
- New AddInvoice row in the inbound actions table: Order payload syncs status and sats to book and DB, keyed by order id; the Peer follow-up (reputation) is ignored. - Column header generalized to local trade row, the table already covered actions affecting both roles. - Stale section heading fixed: the consumer is dispatch_mostro_message over Kind 14 not the long-gone process_gift_wrap_rumor.
|
Warning Review limit reached
Next review available in: 28 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
WalkthroughThe inbound ChangesInbound AddInvoice handling
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related issues
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
rust/src/api/orders.rs (1)
4259-4297: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winExercise the new AddInvoice branches at their call sites.
These tests cover
Payload::Order, zero amounts, and no payload. They do not assert that aPayload::Peerfollow-up returnsNone. The mapping test also does not prove thatclassify_take_reply(&Action::AddInvoice, &None)returnsWaitingBuyerInvoice. Add both assertions.As per coding guidelines, add targeted tests when expanding complex logic, asynchronous workflows, or protocol handling.
Proposed regression assertions
- use mostro_core::message::Payload; + use mostro_core::message::{Payload, Peer}; ... + assert!( + add_invoice_sync(&Some(Payload::Peer(Peer { + pubkey: "peer".to_string(), + reputation: None, + }))) + .is_none() + ); ... fn status_for_action_maps_add_invoice() { + use mostro_core::message::Action; ... + match classify_take_reply(&Action::AddInvoice, &None) { + DaemonReply::TakeAccepted { status, .. } => assert_eq!( + status, + Some(crate::api::types::OrderStatus::WaitingBuyerInvoice) + ), + _ => panic!("expected TakeAccepted"), + } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@rust/src/api/orders.rs` around lines 4259 - 4297, Add assertions to the existing add-invoice tests: verify add_invoice_sync returns None for a Payload::Peer follow-up, and verify classify_take_reply(&Action::AddInvoice, &None) returns WaitingBuyerInvoice. Keep the assertions focused on these two newly exercised branches.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@rust/src/api/orders.rs`:
- Around line 2046-2056: Update the AddInvoice synchronization flow around
order_book().get_order(), order_book().upsert_order(), and
db.update_trade_fields() so the maker-buyer path persists or reconciles the
order-book record even when the cached order is absent, ensuring both target
rows exist before synchronization. Make update_trade_fields() detect and surface
zero-row matches instead of treating them as success, and handle that outcome in
the caller.
---
Nitpick comments:
In `@rust/src/api/orders.rs`:
- Around line 4259-4297: Add assertions to the existing add-invoice tests:
verify add_invoice_sync returns None for a Payload::Peer follow-up, and verify
classify_take_reply(&Action::AddInvoice, &None) returns WaitingBuyerInvoice.
Keep the assertions focused on these two newly exercised branches.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: affbc8c4-88ef-4d8a-9d14-ff0a328d7747
📒 Files selected for processing (2)
rust/src/api/orders.rsspecs/004-mostro-p2p-client/contracts/orders.md
- add_invoice_sync returns None for the daemon's Peer follow-up, so the reputation message cannot clobber the just-written status. - classify_take_reply on a payload-less add-invoice now carries WaitingBuyerInvoice via the new status_for_action mapping; pinned.
![ermeme[bot]](https://avatars.githubusercontent.com/in/3690068?s=60&v=4){kind=small}
There was a problem hiding this comment.
Reviewed the current head.
The AddInvoice ingest path matches the reproduced maker-buyer failure: the inbound Action::AddInvoice with an Order payload now persists WaitingBuyerInvoice plus the calculated sats to both the order book and trade DB, while the follow-up Peer payload is left as a no-op. The take/add-invoice nonce handling and the status_for_action coverage also look consistent with the existing action-only reply flow.
I also rechecked the prior CodeRabbit thread: the zero-row DB no-op is intentional for uncorrelated kind-14 messages, and the remaining cold-cache book gap is shared by other ingest arms rather than an AddInvoice-specific blocker.
Validation:
- GitHub checks are green: Rust, Flutter, and Web all succeeded on this head.
- Local
cargo test --no-default-featurespassed (249 passed, 8 ignored). - Local
cargo clippy --no-default-features -- -D warningspassed. ./scripts/frb-generate.sh --checkpassed.
Non-blocking note: the touched docs still have one older reference to process_gift_wrap_rumor in the same section, but the behavior and new table entry are correct.
1 participant
Closes #287
Problem
The kind-14 ingest (
dispatch_mostro_message) had no arm for an inboundadd-invoice, so it fell into the catch-all and was dropped. That message ishow the daemon asks a maker buyer for their invoice after the seller taker
paid the hold invoice. The trade never reached
WaitingBuyerInvoice, the userwas never prompted to act, and the daemon canceled the order by timeout
(reproduced against a real daemon — see the timeline in #287).
Fix
Action::AddInvoicearm, next to the existingPayInvoiceone. It iskeyed by the message's order id (the message arrives on the global feed with
trade_index=None), and persists the status and the calculated sats to boththe order book and the trade DB.
(
tradeAmountProvider) and refuses an LN address — and NWC auto-generation —without a known amount.
add-invoicecarrying aPayload::Peer(counterpartyreputation) is ignored for now.
status_for_actionnow mapsAddInvoice → WaitingBuyerInvoice, coveringpayload-less messages.
take interception before the per-action arms run.
No Dart changes: with the status persisted, the existing
MyOrderScreenbranch (
waitingBuyerInvoice && !isSelling) already navigates the maker buyerto the add-invoice screen. Global auto-navigation from anywhere in the app is
tracked separately in #283.
Changes
rust/src/api/orders.rs: new ingest arm,add_invoice_synchelper,status_for_actionmapping, unit tests.specs/004-mostro-p2p-client/contracts/orders.md:AddInvoicerow in theinbound actions table; stale section heading fixed (
dispatch_mostro_messageover Kind 14, not the long-gone
process_gift_wrap_rumor).Testing
cargo test(249 passed) andcargo clippy(no new warnings)../scripts/frb-generate.sh --check— no bridge surface changes.Summary by CodeRabbit
New Features
Documentation