src/lightning/invoice.rs (1)

288-291: Zero-amount invoice test: keep the stronger assertion too

Using regtest invoice + None is fine. To preserve the regression check from past learnings (zero-amount must pass even when an expected amount is supplied), add a second assertion that passes Some(amount) and still succeeds.

// Add alongside the existing test
#[tokio::test]
async fn test_zero_amount_invoice_with_expected_amount() {
    init_settings_test();
    let payment_request = "lnbcrt1p5tnk83pp5lqj87uf3ct7e4kluu3zcv3zvav9exwkj7chmpyt3u29g2p7uf6hqdqqcqzzsxqyz5vqsp5mrhkqtp7j8uhfzmcn6wdhj577jm87dvudnf28kefhzwwwh7zp7vq9qxpqysgq7ntan3nl38574gjrjne68740uymnc5xf39yryl9w7y2mcq9p3j53rwquhxukpjzclq4p8qmt89z7r4hmzzjkgj889ujgz0lr55c5gyqqeu4g52".to_string();
    let res = is_valid_invoice(payment_request, Some(10_000), None).await;
    assert_eq!(Ok(()), res);
}

src/db.rs (1)

449-454: Run under a transaction and guard against cross-process races

For existing DBs, consider acquiring an immediate transaction before migration to avoid TOCTOU if multiple instances start simultaneously and attempt the drop/rebuild concurrently.

-// Run legacy column migration for existing databases
-if let Err(e) = migrate_remove_token_columns(&conn).await {
+// Run legacy column migration under transactional guard
+if let Err(e) = migrate_remove_token_columns(&conn).await {
     tracing::error!("Failed to migrate token columns on existing database: {}", e);
     return Err(e);
 }

Note: with the refactor above, migrate_remove_token_columns itself begins/commits the transaction.

src/app/dispute.rs (2)

107-108: Typo in comment

Minor clarity fix.

-    // Message to discounterpart
+    // Message to counterpart

---

69-80: Docstring doesn’t match function signature/behavior

Function returns only a boolean (buyer initiated) or an error, not a tuple/photos of counterpart.

-/// Returns a tuple containing:
-/// - The counterparty's public key as a String
-/// - A boolean indicating if the dispute was initiated by the buyer (true) or seller (false)
+/// Returns:
+/// - Ok(true) if the dispute was initiated by the buyer
+/// - Ok(false) if initiated by the seller
+/// - Err(CantDoReason::InvalidPubkey) if the sender matches neither party

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: arkanoider
PR: MostroP2P/mostro#499
File: src/lightning/invoice.rs:108-114
Timestamp: 2025-07-17T13:51:17.338Z
Learning: In Lightning invoice validation for Mostro buy orders (src/lightning/invoice.rs), zero-amount invoices (amount_sat == 0) should always pass validation even when an expected amount is provided. This is because users can submit invoices at order creation time before knowing the exact satoshi amount they'll receive. The condition `if amount_sat != res && amount_sat != 0` correctly implements this by allowing zero-amount invoices to pass while enforcing exact amount matching for non-zero invoices.