apiRequest's 429 handling ignores Retry-After in HTTP-date form, and its `|| "Rate limited..."` fallback message is dead code

[chonilius]

Problem

src/lib/api.ts → apiRequest(), from the rate-limit handling added in #44:

if (res.status === 429) {
  const retryAfter = res.headers.get("Retry-After");
  const seconds = retryAfter ? parseInt(retryAfter, 10) : NaN;
  const waitMsg = Number.isFinite(seconds)
    ? ` Please wait ${seconds} second${seconds === 1 ? "" : "s"} before trying again.`
    : "";
  throw new ApiRequestError(
    `You're doing that too fast.${waitMsg}` || `Rate limited. Please try again later.`,
    429,
    Number.isFinite(seconds) ? seconds : undefined,
  );
}

1. HTTP-date Retry-After is dropped. RFC 9110 §10.2.3 allows Retry-After to be either delay-seconds or an HTTP-date, such as Retry-After: Wed, 21 Oct 2026 07:28:00 GMT, which proxies and CDNs commonly send. parseInt("Wed, 21 Oct…", 10) is NaN, so the wait time disappears from both the message and ApiRequestError.retryAfter. Callers that read retryAfter to throttle retries get undefined.
2. The fallback message is unreachable. The left side of || is a template literal that always starts with "You're doing that too fast.", so it's always truthy. "Rate limited. Please try again later." can never be used, which suggests the intended "no wait info" message was lost.

Suggested fix

• Parse both forms. Use the seconds if /^\d+$/ matches. Otherwise use Date.parse(value) and compute Math.max(0, Math.ceil((date - Date.now()) / 1000)).
• Choose the message explicitly: the "wait N seconds" wording when seconds are known, and the plain fallback otherwise. Remove the dead ||.
• Add unit tests for delay-seconds, an HTTP-date, a missing header and a garbage header value. lib/api.ts has limited coverage (lib/api.ts (request dedup, timeout, rate-limit handling) has zero test coverage #370).

Related: #44, #370.

[drips-wave]

@chonilius This issue could not be added to the Stellar Wave Program because the per-repo points budget would be exceeded (25000 / 25000 points already used). The label has been automatically removed.

The budget resets at the end of each Wave. You can review the remaining budget for your repos on the Orgs & Repos page.

ℹ️ Learn more about points budgets

[Ranjeet2063]

Hello maintainers,

I would like to take on and implement this issue: apiRequest's 429 handling ignores Retry-After in HTTP-date form, and its || "Rate limited..." fallback message is dead code.

Technical Implementation Roadmap:

1. Deep Codebase Audit: Inspect current architecture and data flows in MergeFi/frontend to design an optimal, idiomatic solution.
2. Core Modular Implementation: Implement apiRequest's 429 handling ignores Retry-After in HTTP-date form, and its || "Rate limited..." fallback message is dead code with clean separation of concerns and robust error handling.
3. Comprehensive Automated Test Matrix: Add end-to-end integration and unit tests covering positive execution and edge failure modes.
4. Production CI Verification: Ensure all linters, formatting checks, and GitHub Actions workflows pass with 100% green status.

I have worked extensively on similar architectures and can deliver this cleanly within 24 hours. Please assign to me!

[guptakumarranjeet150]

Hi team,

Happy to tackle this. Here is how I plan to implement it:

Proposed steps:

1. Inspect repository architecture in MergeFi/frontend for an idiomatic solution.
2. Implement the feature/fix with clean modular separation and robust error handling.
3. Add comprehensive unit and integration test coverage for all edge cases.
4. Verify that all linters, formatting, and CI checks pass cleanly.

Could you please assign this issue to me? Looking forward to delivering a clean PR.

[ranjeet150]

Hello maintainers,

I am interested in taking up apiRequest's 429 handling ignores Retry-After in HTTP-date form, and its || "Rate limited..." fallback message is dead code.

Proposed steps:

1. Inspect repository architecture in MergeFi/frontend for an idiomatic solution.
2. Implement the feature/fix with clean modular separation and robust error handling.
3. Add comprehensive unit and integration test coverage for all edge cases.
4. Verify that all linters, formatting, and CI checks pass cleanly.

I can deliver a clean, tested PR within 24 hours. Please assign!

[shobhamerabacha-star]

Hello maintainers,

I am interested in taking up apiRequest's 429 handling ignores Retry-After in HTTP-date form, and its || "Rate limited..." fallback message is dead code.

Proposed steps:

1. Inspect repository architecture in MergeFi/frontend for an idiomatic solution.
2. Implement the feature/fix with clean modular separation and robust error handling.
3. Add comprehensive unit and integration test coverage for all edge cases.
4. Verify that all linters, formatting, and CI checks pass cleanly.

Let me know if this aligns with the repository guidelines and assign when convenient.

[ravimahatonp]

Hello maintainers,

I am interested in taking up apiRequest's 429 handling ignores Retry-After in HTTP-date form, and its || "Rate limited..." fallback message is dead code.

Implementation approach:

1. Inspect repository architecture in MergeFi/frontend for an idiomatic solution.
2. Implement the feature/fix with clean modular separation and robust error handling.
3. Add comprehensive unit and integration test coverage for all edge cases.
4. Verify that all linters, formatting, and CI checks pass cleanly.

Please assign this to me if the plan looks good. Thanks!

[Proxima84-code]

Submitted fix and unit tests covering delay-seconds and HTTP-date Retry-After forms via #586.

[Proxima84-code]

Submitted fix and unit tests covering delay-seconds and HTTP-date Retry-After forms via #586.