fix: skip 400 responses in getCoinpayGlobalWalletTokens to allow fall…

[emil07770]

…back URLs

The getCoinpayGlobalWalletTokens function tries 3 CoinPay API endpoints in order but throws on HTTP 400 instead of continuing to the next URL. Adding 400 to the skip list allows fallback to /api/wallets and /api/businesses/{id} when /api/get-tokens returns 400.

[greptile-apps]

Greptile Summary

Adds HTTP 400 to the set of status codes that trigger a continue (fallback to the next URL) instead of a hard throw inside getCoinpayGlobalWalletTokens. Previously, a 400 from /api/get-tokens caused the function to throw immediately, preventing it from trying /api/wallets and /api/businesses/{id}.

• The one-line change extends the skip-list from [401, 403, 404] to [400, 401, 403, 404], so a 400 on any of the three fallback URLs is now treated the same as a 401/403/404 — the error is recorded and the loop continues.
• The existing error-surfacing logic (!sawSuccessfulResponse && errors.length > 0) is unchanged, so if all endpoints return 400, the function still throws with the first collected error message.

Confidence Score: 4/5

The change is safe to merge; the worst case is two extra API calls before the existing error-throw path is reached.

The change is minimal and the fallback loop already has correct final-error-surfacing logic, so correctness is maintained. The only open question is whether 400 can indicate a request-level misconfiguration that applies to all three endpoints equally, which would make the extra calls wasteful — but this does not break anything.

src/lib/coinpayportal.ts — specifically the skip-list at line 564 and its interaction with the !sawSuccessfulResponse error path at line 574.

Important Files Changed

Filename	Overview
src/lib/coinpayportal.ts	Adds HTTP 400 to the skip-and-continue list in the fallback URL loop of getCoinpayGlobalWalletTokens so a 400 from /get-tokens no longer hard-throws and instead falls through to /wallets and /businesses/{id}.

Sequence Diagram

sequenceDiagram
    participant Client
    participant GetTokens as /api/get-tokens
    participant Wallets as /api/wallets
    participant Businesses as /api/businesses/{id}

    Client->>GetTokens: GET with Bearer token
    alt 400 response
        GetTokens-->>Client: 400 Bad Request
        note over Client: continue to next URL (new behavior)
        Client->>Wallets: GET with Bearer token
        alt 200 OK
            Wallets-->>Client: 200 + wallet list
            Client-->>Client: return wallets
        else 4xx skip code
            Wallets-->>Client: 4xx
            Client->>Businesses: GET with Bearer token
            alt 200 OK
                Businesses-->>Client: 200 + wallet list
                Client-->>Client: return wallets
            else all failed
                Businesses-->>Client: 4xx
                Client-->>Client: throw Error with first error
            end
        end
    else 200 OK
        GetTokens-->>Client: 200 + wallet list
        Client-->>Client: return wallets
    else 5xx or unrecognized 4xx
        GetTokens-->>Client: 5xx
        Client-->>Client: throw immediately
    end

Loading

_{Reviews (1): Last reviewed commit: "fix: skip 400 responses in getCoinpayGlo..." | Re-trigger Greptile}

[greptile-apps]

400 may also silence client-side misconfiguration on all three endpoints

HTTP 400 (Bad Request) typically signals a permanent client-side error — for example, a malformed business_id, an unsupported API version, or an invalid bearer token format. Because that root cause applies equally to all three URLs, adding 400 to the skip list can cause two extra round-trips before the function eventually throws via the !sawSuccessfulResponse path, with the diagnostic message buried in errors[0]. If CoinPay returns 400 specifically for endpoint-level reasons (e.g., /get-tokens requires a plan upgrade), the fallback is correct; but if it signals a request-level misconfiguration that affects all endpoints, the extra calls add latency without value. Consider whether a comment documenting the specific CoinPay behaviour that motivated this change would help future maintainers distinguish the two cases.