refactor: make retryPayment client-side [AMB-3091] - #51
Draft
bufo24 wants to merge 3 commits into
Draft
Conversation
Retries a FAILED send transaction, reusing its stored payment_request (no new invoice minted), and pays it against the node the same way send() does. Calls the retry_send mutation, hand-authored against amboss-rails-api#577 (unmerged, not yet deployed) the same way mintStreamToken was hand-authored for AMB-3016 — codegen only generates against the live schema. TODO(AMB-3091) left in resources/retrySend.ts and retrySend.types.ts: once #577 merges and deploys, refresh the schema, run codegen, and delete both files in favor of the generated operation.
bufo24
changed the title
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.
Summary
Transactions.retryPayment(paymentId: string): Promise<SendResult>retries aFAILEDsend client-side: looks up the transaction, validates it's retryable (statusFAILED, invoice not expired, has apayment_request), then resends thatpayment_requestthrough the existingsend()/create_sendpath with a fresh idempotency key. No dedicated server-sideretry_sendmutation involved.send()'s actual node-payment logic (macaroon resolution via#sendContext,sendLndPayment/sendAssetPayment) rather than duplicating it.prepareSend's cached macaroon, same as a password-lesssend(); fails the same way (PaymentSendError) when nothing is cached.PaymentSendErrorif the transaction isn't retryable (wrong status, expired invoice, or missingpayment_request) instead of silently proceeding.Scope change
Originally implemented against a
retry_sendmutation planned inamboss-rails-api#577. That mutation is being removed from #577 by a parallel effort (AMB-3092) — retry is now client-side instead, so this SDK has no dependency on #577 or any other unreleased backend change. Deleted the hand-authoredretrySend.ts/retrySend.types.tsfiles, since the whole point of client-side retry is that no new mutation is needed.Test plan
pnpm run buildpnpm run typecheckpnpm run test(62/62 passing, including 6 tests intransactions.retryPayment.test.ts: resends via a prepared macaroon, throwsPaymentSendErrorwith nothing prepared, returnspayment: nullfor sandbox, and throws for non-FAILEDstatus / expired invoice / missingpayment_request)🤖 Generated with Claude Code