Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/lib/coinpayportal.ts
Original file line number Diff line number Diff line change
Expand Up @@ -561,7 +561,7 @@ export async function getCoinpayGlobalWalletTokens(
if (!response.ok) {
const text = await response.text().catch(() => "");
errors.push(`${url.pathname}: ${response.status}${text ? ` ${text.slice(0, 120)}` : ""}`);
if ([401, 403, 404].includes(response.status)) continue;
if ([400, 401, 403, 404].includes(response.status)) continue;
throw new Error(`CoinPay get-tokens failed: ${response.status}`);
Comment on lines +564 to 565
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 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.

}

Expand Down