Fix invoice tracking for retried payments (issue #864)

[grunch]

Summary

This PR fixes a critical issue where retried payments were overwriting the original buyer invoice, losing audit trail information. The solution introduces a new buyer_invoice_paid field to track the invoice that was actually paid while preserving the original buyer_invoice for reconciliation and debugging.

Key Changes

• New field buyer_invoice_paid: Added to the Order schema to store the invoice that was actually paid, separate from the original buyer_invoice
• Updated completeOrderAsSuccess: Now accepts an optional paidInvoice parameter that is recorded atomically in the database update, ensuring the paid invoice is captured without losing the original
• Updated healConfirmedOrder: Now forwards the paid invoice information through the call chain so confirmed orders also record the real paid invoice
• Enhanced pending payment retry logic: The attemptPendingPayments job now passes the actual paid invoice (pending.payment_request) to completion routines in three scenarios:
  • When the original invoice is already confirmed
  • When a previous pending payment is discovered to be paid
  • When the current pending payment confirms successfully
• Improved logging: Enhanced log message to include the actual payment hash (payment.id) instead of the hold invoice hash for clarity
• Updated invoice submission flow: The /setinvoice scene now records the submitted invoice as the paid invoice when healing a confirmed order

Implementation Details

• The paidInvoice parameter is optional to maintain backward compatibility
• Database updates use atomic $set operations to ensure consistency
• In-memory order objects are kept synchronized with database state
• All three code paths that complete orders successfully now properly track which invoice was actually paid
• Comprehensive test coverage added for both the job retry logic and the completion routine

Testing

Added regression tests covering:

• Successful retry payment recording the new invoice in buyer_invoice_paid while preserving the original
• Failed payment attempts leaving both invoice fields untouched
• Atomic database updates with proper field isolation
• Race condition handling when multiple processes attempt completion

https://claude.ai/code/session_01Pid19awYpjQUa2cRZKnRaD

Summary by CodeRabbit

• New Features
  • Orders now persist a separate buyer_invoice_paid value to record the invoice that was actually paid, while preserving the original buyer_invoice.
• Bug Fixes
  • Payment reconciliation for confirmed and retried payments now records the correct paid invoice and avoids overwriting the original buyer invoice.
  • Success handling now reports the real confirmed payment details and updates routing fee from the confirmed payment.
• Tests
  • Added regression tests covering successful/failed payment retries, invoice preservation, and compare-and-set behavior to prevent race-condition inconsistencies.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 7f9faabb-c4af-4a9c-8e23-bee2ec9d2d62

📥 Commits

Reviewing files that changed from the base of the PR and between ce3fddb and 1ca08d1.

📒 Files selected for processing (1)

• ln/pay_request.ts

---

Walkthrough

Changes

Paid invoice reconciliation

Layer / File(s)	Summary
Completion contract and persistence models/order.ts, util/completeOrder.ts, tests/util/completeOrder.spec.ts	Adds optional buyer_invoice_paid persistence and coverage for successful updates, omitted values, and CAS race loss.
Pending payment reconciliation jobs/pending_payments.ts, tests/jobs/pending_payments.spec.ts	Passes paid invoice identifiers through healing and completion paths, updates payment logging, and tests success and failure behavior.
Invoice wizard healing integration bot/scenes.ts	Passes the confirmed buyer invoice as the paid invoice during wizard healing.
Direct payment recording ln/pay_request.ts	Records the buyer invoice as paid after successful payment confirmation.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Possibly related issues

• lnp2pBot/bot#864 — Covers recording retry invoices separately through pending-payment reconciliation and order completion.

Possibly related PRs

• lnp2pBot/bot#831 — Modifies overlapping pending-payment and buyer-payment processing paths.
• lnp2pBot/bot#844 — Modifies the confirmed-payment healing and invoice reconciliation flows.
• lnp2pBot/bot#875 — Extends overlapping successful buyer-payment metadata updates.

Suggested reviewers: knocte

Poem

A rabbit follows invoices bright,
Keeping the first one safely in sight.
The paid one hops to its own new field,
While healing paths their records yield.
Success drums softly through the night.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main change: preserving and recording the paid invoice for retried payments.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/pr-866-comments-wllhxc

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Luquitasjeffrey]

The buyer_invoice_paid field is only set if the order enters in the "pending payments" path, if the first attempt succeeds, the order transitions to SUCCESS state without setting the buyer_invoice_paid field.

Suggested fix:
set the 'buyer_inovice_paid' field in the payToBuyer function

[Luquitasjeffrey]

tACK
Now it stores the invoice actually paid on the first payment attempt and l+all the subsequential payment attempts if the first one fails