Skip to content

Fix inverted error handling logic in CheckoutForm (FRONTEND-REACT-6DK)#1423

Draft
cursor[bot] wants to merge 1 commit intomasterfrom
error-500---b7s69d
Draft

Fix inverted error handling logic in CheckoutForm (FRONTEND-REACT-6DK)#1423
cursor[bot] wants to merge 1 commit intomasterfrom
error-500---b7s69d

Conversation

@cursor
Copy link
Copy Markdown

@cursor cursor bot commented Apr 9, 2026

Summary

Fixes FRONTEND-REACT-6DK - Resolves incorrect error throwing for valid HTTP 500 responses in the checkout form.

Problem

The checkout function in CheckoutForm.jsx had inverted conditional logic that caused it to throw a new Error for valid HTTP error responses (like 500 status codes). This happened because:

  1. When fetch() receives an HTTP 500 response, it returns a Response object with ok: false and status: 500
  2. The response.error property is undefined for HTTP responses (it's only set by the custom .catch() handler for network errors)
  3. The buggy condition !response.error || response.status === undefined evaluated to true for HTTP errors
  4. This caused line 108 to throw a new error on top of the backend's legitimate error

Solution

Removed the throw new Error() statement from the else block that handles valid HTTP error responses. Now the code:

  • Network errors (when response.error exists): Properly captured via Sentry
  • HTTP error responses (4xx/5xx with valid status): Tracked in metrics but don't throw a new error

This prevents the frontend from incorrectly navigating to the error page when the backend returns expected error responses like inventory validation failures.

Changes

  • Modified the conditional logic in the checkout() function to only capture errors for network failures
  • Valid HTTP error responses now set status attributes and metrics without throwing

Testing

The fix ensures that when the backend returns an HTTP 500 due to inventory validation failure, the frontend will:

  • Track the error status in metrics
  • Not throw an additional error
  • Handle the response gracefully instead of navigating to the error page
Open in Web Open in Cursor 

Fixes FRONTEND-REACT-6DK

The checkout function was incorrectly throwing a new Error for valid HTTP
error responses (like 500) due to inverted logic. The condition
'!response.error || response.status === undefined' would be true for
normal HTTP error responses since response.error is undefined in those
cases (fetch only sets response.error for network failures).

This caused the frontend to throw an unnecessary error on top of backend
errors, triggering the error page navigation when it shouldn't.

Fixed by removing the throw statement from the else block, so valid HTTP
error responses are tracked in metrics but don't cause a new error to be
thrown. Network errors are still properly captured via Sentry.
@vercel
Copy link
Copy Markdown
Contributor

vercel bot commented Apr 9, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
empower Ignored Ignored Apr 9, 2026 6:57pm

Request Review

@codecov
Copy link
Copy Markdown

codecov bot commented Apr 9, 2026

⚠️ JUnit XML file not found

The CLI was unable to find any JUnit XML files to upload.
For more help, visit our troubleshooting guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant