fix: use task stored API config as fallback for rate limit

[roomote]

Fixes a bug where rate limiting would be silently disabled in edge cases when provider state is unavailable.

Problem

In Task.ts, the rate limit is read from the provider state in two locations:

• Line 3643 in attemptApiRequest
• Line 3974 in backoffAndAnnounce

When state is undefined/null (provider reference lost or getState() fails), the rate limit defaults to 0, effectively disabling rate limiting.

Solution

Use the task's stored configuration as a fallback:

const rateLimit = (apiConfiguration ?? this.apiConfiguration)?.rateLimitSeconds || 0

This ensures:

• The most up-to-date configuration from state is preferred
• If state is unavailable, the task's stored configuration is used as fallback
• Rate limiting is only disabled if neither source has a configuration

Impact

This bug rarely manifests since getState() usually succeeds. However, in edge cases where the provider reference is temporarily unavailable, users' configured rate limits would be silently ignored, potentially causing API rate limit errors.

Testing

• All existing tests pass (34 passed)
• Linting passes
• Type checking passes

---

View task on Roo Code Cloud

---

Important

Fixes rate limiting bug in Task.ts by using task's stored configuration as fallback when provider state is unavailable.

• Behavior:
  • Fixes bug in Task.ts where rate limiting was disabled when provider state was unavailable.
  • Uses task's stored configuration as fallback for rate limit in attemptApiRequest and backoffAndAnnounce.
  • Rate limiting is only disabled if neither source provides a configuration.
• Impact:
  • Prevents silent disabling of rate limits in edge cases, reducing potential API rate limit errors.
• Testing:
  • All existing tests pass (34 passed).
  • Linting and type checking pass.

^{This description was created by for f3caed7. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Rooviewer   See task on Roo Cloud

Review complete. No issues found.

The changes correctly implement a fallback mechanism for rate limiting when provider state is unavailable:

• Both modifications follow the same consistent pattern using nullish coalescing (??)
• this.apiConfiguration is guaranteed to be defined (set in constructor from required parameter)
• The fix preserves existing behavior when state is available while providing a sensible fallback

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[roomote]

Rooviewer   See task on Roo Cloud

Review complete. No issues found.

The changes correctly implement a fallback mechanism for rate limiting when provider state is unavailable:

• Both modifications follow a consistent pattern using nullish coalescing (??)
• this.apiConfiguration is guaranteed to be defined (set in constructor from required parameter)
• The fix preserves existing behavior when state is available while providing a sensible fallback

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[mrubens]

This seems fine, but why do we ever use apiConfiguration from state? Should we not just use this.apiConfiguration everywhere?

[daniel-lxs]

@mrubens
I agree, in that case do we need apiConfiguration to be in the state at all?