Add more robust error handling to SwipeChart

[j0ntz]

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

• Yes
• No

Dependencies

none

Description

Context

The SwipeChart component fetches market data from CoinGecko API and has insufficient error handling for network failures and rate-limiting scenarios. When rate limits or HTTP errors occur, the error handling is ambiguous and can fail silently, making debugging difficult.

Changes

• Added HTTP status validation: Check response.ok before parsing JSON to catch non-2xx status codes early
• Improved JSON parsing: Added try-catch around JSON parsing with fallback to raw text for error messages
• Better rate-limit handling: Explicit HTTP 429 detection before JSON parsing phase
• Enhanced error messages: More descriptive error text for HTTP errors and JSON parsing failures
• Restructured error handling: Wrapped the retry loop in a try-catch to ensure setIsFetching(false) is always called via finally block

These changes make the component more resilient to API failures and easier to debug when issues occur.

Requirements

If you have made any visual changes to the GUI. Make sure you have:

• Tested on iOS device
• Tested on Android device
• Tested on small-screen device (iPod Touch)
• Tested on large-screen device (tablet)

---

Note

Low Risk
Localized UI data-fetch error-handling and lint config tweak; minimal behavioral risk beyond how chart errors/retries are surfaced.

Overview
Improves SwipeChart market-data fetching resilience by validating response.ok, explicitly handling HTTP 429 rate limits (including retry + pro-key fallback), and safely parsing JSON via text() with clearer error messages.

Ensures setIsFetching(false) always runs via a finally, and updates lint config to stop excluding SwipeChart.tsx from linting; adds a matching CHANGELOG entry.

^{Written by Cursor Bugbot for commit 3b79cde. This will update automatically on new commits. Configure here.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ea8c620be5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Unbounded retry loop on 429 can spin forever

High Severity

The do...while(true) loop retries indefinitely on HTTP 429 responses with no maxRetries counter or exit condition beyond eventual success. If the API keeps rate-limiting, the loop never exits, setIsFetching(false) in the outer finally is never reached, and the user sees a permanent loading spinner. The PR discussion states that maxRetries (increased from 3 to 5) and exponential backoff were added, but neither is present in the code. The codebase already has a bounded retry pattern in FirstOpenActions.tsx using a for loop with maxRetries.

Additional Locations (1)

• src/components/charts/SwipeChart.tsx#L355-L358

 

[cursor]

Duplicate 429 retry logic may drift

Low Severity

Two nearly identical blocks handle 429 retries — one for the HTTP status code (before JSON parsing) and one for the JSON body error code (after parsing). Both perform the same pro-URL fallback check, snooze(2000), and continue. If future changes update one block (e.g., adding a retry counter or exponential backoff), the other could easily be missed, leading to inconsistent retry behavior.

Additional Locations (1)

• src/components/charts/SwipeChart.tsx#L321-L332