fix: keep amt and fa tags consistent during the taker-bond window - #928
fix: keep amt and fa tags consistent during the taker-bond window#928Forte11Cuba wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. WalkthroughThe changes reject partial range orders, keep NIP-33 range publication consistent during ChangesTaker bond recovery and order state handling
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: 🟠 High · up to The new stale-bond recovery can release and overwrite a taker bond after a valid payment has locked it, potentially allowing an order or trade to proceed without the intended anti-abuse bond. The cleanup transition needs an atomic state-and-age guard before this PR is ready to merge. Sequence Diagram(s)sequenceDiagram
participant Scheduler
participant BondFlow
participant BondDatabase
participant OrderStore
participant Nostr
Scheduler->>BondFlow: Run reconciliation every 300 seconds
BondFlow->>BondDatabase: Find stale WaitingTakerBond orders
BondDatabase-->>BondFlow: Return eligible orders
BondFlow->>OrderStore: Re-check bond state and age
BondFlow->>OrderStore: Release stale Requested bond
BondFlow->>OrderStore: Set order to Pending
BondFlow->>Nostr: Republish order as Pending
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Linked Issues checkExplanation The changes satisfy issue
✨ Finishing Touches🧪 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 |
Closes #927
A range order being taken published a contradictory event: the range in
fanext to the taker's quote inamt, while still showings: pending. The order was fine in the DB — the event was built from the in-memory struct thattake_sell/take_buymutate before theWaitingTakerBondrepublish.Part 1 nip33:
faandamtnow share a singlepublishes_as_pending()predicate. While a range order publishes as pending,amtstays"0"— byte-identical to the Pending event it replaces, so no client changes needed.Part 2 scheduler sweep: if the LND cancel signal is missed, the order no longer sits at
WaitingTakerBondfor up to 24 h. A job runs every 300 s, releases demonstrably staleRequestedtaker bonds and drops the order back toPending. One deviation from the issue: calling onlymaybe_drop_waiting_taker_bondwould never fire (its CAS no-ops while arequestedbond exists — exactly the stranded state), so the sweep releases those bonds first via the existingrelease_bond. The per-order step re-checks bond state and age at action time, since a concurrent take can land between the scan and the release.Part 3 order creation: half-specified ranges (min xor max) are now rejected with
InvalidAmount. They used to slip past bothcheck_fiat_amountandcheck_range_order_limitsand get persisted with a fixed sats price and no fiat amount.Tested manually on regtest (Polar with a real LND node): took a range order of 5000-10000 CUP and let the bond expire without paying. The event kept
amt: "0"and the full range infaduring the whole bond window, and since LND's cancel signal genuinely never arrived, the sweep recovered the order back toPendingin about 6 minutes. Also adds 6 new unit tests; full suite passes (1250 tests) and clippy is clean.Summary by CodeRabbit
New Features
Bug Fixes