Repository navigation
Conversation
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dependency Review✅ No vulnerabilities found.Scanned FilesNone |
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: agedd <ageddam@paypal.com>
| ): BrowserSwitchException? { | ||
| if (pendingRequestString.isEmpty()) return null | ||
| return try { | ||
| payPalLauncher.restorePendingRequest(pendingRequestString) | ||
| null | ||
| } catch (e: BrowserSwitchException) { | ||
| e | ||
| } |
There was a problem hiding this comment.
This function signature is a bit unusual being a nullable exception as the return type. Is it going to be re-used elsewhere? I think my preference would be to lift the try/catch to consumers, but then I don't know what utility this function would bring at all then either.
| callback.onPayPalResult(PayPalResult.Failure(error)) | ||
| setButtonReEnabled() | ||
| return | ||
| } |
There was a problem hiding this comment.
I think we should have tests to cover the behavior of the PayPalButton.kt too, since that's what we're altering the behavior of here.
There was a problem hiding this comment.
yep, added PayPalButtonUnitTest, using an internal constructor like VenmoButton. it covers restore running before handleReturnToApp, the restore-failure path, and the success, no result and failure results.
| callback: PayPalTokenizeCallback | ||
| ) { | ||
| restorePendingRequest(payPalLauncher, pendingRequest.pendingRequestString)?.let { error -> | ||
| callback.onPayPalResult(PayPalResult.Failure(error)) |
There was a problem hiding this comment.
Do we need to emit any failure analytic event here?
There was a problem hiding this comment.
ah good callout, we don’t need one here, since the error still reaches the merchant via PayPalResult.Failure and the other UI components don't emit their own failure events.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Summary of changes
PayPalButton.RestorePendingRequest.ktwith a small helper, and unit tests for it.Why
PayPalLauncheruses Chrome Auth Tab for the web flow and only keeps the pending request in memory. When theActivity is recreated while the browser is open (for example "Don't keep activities", or a low-memory device), the
new launcher has no pending request, so the result can't be completed and the button reports a cancel instead of
returning a nonce, even though the buyer finished PayPal. Restoring the stored request first fixes it, which is the
same step the SDK's demo screens already do.
Testing
"User did not complete payment flow").
AI Usage
code generation and refactor
Checklist
Authors
@agedd