MostroP2P/mostro

Summary #848 changes dispute_action so that a setup_dispute failure is propagated to the client instead of being silently swallowed. That is the right call, but the new error arm has no test: grep -rn "DisputeCreationError" src/ returns nothing. This is a behavior change on a user-facing protocol response, so it should be pinned by a test before it can regress. Context Before #848, src/app/dispute.rs did: if order.setup_dispute(is_buyer_dispute).is_ok() { order.clone().update(pool).await.map_err(...)?; } // execution continued, and the dispute row was created anyway On failure this skipped order.update() but kept going, creating a disputes row while leaving the order flags unset. After #848: order.setup_dispute(is_buyer_dispute).map_err(MostroCantDo)?; order.clone().update(pool).await.map_err(...)?; The caller now receives CantDo(DisputeCreationError) and no dispute row is created. setup_dispute (mostro-core 0.14.5, order.rs:522) returns Err(CantDoReason::DisputeCreationError) only

If an order reaches the settled-hold-invoice status but the Lightning payment to the buyer invoice fails, Mostro sends an add-invoice action request so the user can provide a new invoice. However, if the user performs a restore-session at this point, Mostro only returns the order with status settled-hold-invoice, does not resend the add-invoice action or any signal indicating that the previous payment attempt failed. Because of this, the app has no way to know that: the invoice payment failed, and the buyer must provide a new invoice. As a result, the order appears as successfully settled, while in reality the buyer has not been paid and has no way to receive their sats anymore.