fix(payments): settle through the admin client — RLS silently voided recipient confirmation - #534
Merged
Merged
Conversation
…recipient confirmation Found by a live end-to-end simulation: RLS grants UPDATE on payment_intents to buyers only, so a recipient confirming an acknowledged bare-Lightning payment updated ZERO rows with no error. claimPaidTransition misread that as "another observer already settled it", skipped every side-effect (notification, funding, order), and sellerConfirmPayment still answered "paid". The recipient-confirmation flow had never worked in production. A status transition is a system fact recorded AFTER the caller was authorized — the caller's RLS visibility must never decide it: - claimPaidTransition / updatePaymentStatus / handlePaymentConfirmed now write through the admin client (side-effects span multiple users' data: buyer's order, seller's notification, entity inventory). - checkNWCPaymentStatus reads the seller's wallet via admin too — it only worked under caller clients because wallets_select is currently public-read; tightening that policy must not silently kill detection. - seller_confirm on a non-awaiting intent now returns 400, not 500. - Regression test pins the transition to the admin client and asserts the caller-scoped client is never asked to write. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by a live end-to-end payment simulation (no real money): RLS grants UPDATE on
payment_intentsto buyers only, so a recipient confirming an acknowledged bare-Lightning payment updated zero rows with no error — misread as a lost settle race, every side-effect skipped, API still answered "paid". The recipient-confirmation flow had never worked in production.Status transitions are system facts recorded after authorization; they now write through the admin client (
claimPaidTransition,updatePaymentStatus,handlePaymentConfirmed, and the NWC wallet read incheckNWCPaymentStatus).seller_confirmon a non-awaiting intent returns 400 instead of 500. Regression test pins the transition to the admin client.🤖 Generated with Claude Code