fix: handle PayPal transport errors and clear Express spinner - #774
fix: handle PayPal transport errors and clear Express spinner#774Ali Ghanei (Aliaaaam) wants to merge 3 commits into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2267c8b436
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "Codex (@codex) address that feedback".
|
|
||
| ElementLoadingIndicatorUtil.remove(document.body); | ||
|
|
||
| if (request.status === 400) { |
There was a problem hiding this comment.
When the new backend path returns a 502 PayPalApiException from /paypal/express/prepare-checkout, this condition still only parses 400 responses; the non-400 path falls through to this.onError() without the response body. In the inspected onApprove/handleError flow, that discards the ErrorResponseFactory code and stores SWAG_PAYPAL__EXPRESS_GENERIC_ERROR, so the transport-specific error added in this commit never reaches buyers for prepare-checkout failures. Pass the response payload to onError for non-400 errors too.
Useful? React with 👍 / 👎.
| $response = $this->client->sendRequest($request); | ||
| try { | ||
| $response = $this->client->sendRequest($request); | ||
| } catch (ClientExceptionInterface $e) { |
There was a problem hiding this comment.
RequestExceptionInterface failures from the underlying PSR client also extend ClientExceptionInterface, so this catch now classifies malformed request/stream problems as PayPal network outages and turns them into a 502 NETWORK_ERROR. In contexts where the SDK or plugin builds an invalid request, that hides the real defect from callers and customer-facing errors; catch NetworkExceptionInterface for transport failures and let request exceptions surface separately.
Useful? React with 👍 / 👎.
3 participants
1. Why is this change necessary?
Transient PayPal API transport failures (e.g. short DNS outages) during Express
prepare-checkoutcurrently surface as HTTP 500, and the Express loading spinner is never cleared on the error path, leaving buyers stuck with no recovery.2. What does this change do, exactly?
ClientExceptionInterfaceto a customer-facingPayPalApiException(502 /NETWORK_ERROR) instead of an unhandled 500paypal.base-clientfor idempotent GETsonApprove/ error handling failure paths3. Describe each step to reproduce the issue or behaviour.
POST /paypal/express/prepare-checkoutto 500 (DevTools)Same flow with DNS/connect failure to
api-m.paypal.com-> unhandled 500 fromClient.php.4. Please link to the relevant issues (if any).
5. Checklist