fix: handle rate_limit_count=0 to prevent IndexError

[bobo-xxx]

When rate_limit_count is set to 0 (disabling rate limiting), messages fail with IndexError because the check is always False when rate_limit_count is 0, causing execution to fall through to timestamps[0] access on an empty deque.

Changed the condition to so that count=0 means no rate limiting is applied.

Fixes #7619

Summary by Sourcery

Bug Fixes:

• Avoid IndexError in the rate limiting pipeline stage when rate_limit_count is set to zero or a negative value, by skipping rate checks in that case.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• Consider handling rate_limit_count <= 0 earlier (e.g., at initialization or with an early return) so this branch can stay focused on the normal rate-limiting path and avoid per-call checks when rate limiting is disabled.
• If negative values for rate_limit_count are not meaningful, it may be clearer to check == 0 here and/or normalize the config to 0 at load time rather than treating all <= 0 as the same case.
• It could be helpful to document in the surrounding code or configuration comments that rate_limit_count=0 disables rate limiting so this behavior is explicit to future maintainers.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider handling `rate_limit_count <= 0` earlier (e.g., at initialization or with an early return) so this branch can stay focused on the normal rate-limiting path and avoid per-call checks when rate limiting is disabled.
- If negative values for `rate_limit_count` are not meaningful, it may be clearer to check `== 0` here and/or normalize the config to `0` at load time rather than treating all `<= 0` as the same case.
- It could be helpful to document in the surrounding code or configuration comments that `rate_limit_count=0` disables rate limiting so this behavior is explicit to future maintainers.

## Individual Comments

### Comment 1
<location path="astrbot/core/pipeline/rate_limit_check/stage.py" line_range="66" />
<code_context>
                 self._remove_expired_timestamps(timestamps, now)

-                if len(timestamps) < self.rate_limit_count:
+                if self.rate_limit_count <= 0 or len(timestamps) < self.rate_limit_count:
                     timestamps.append(now)
                     break
</code_context>
<issue_to_address>
**suggestion:** Clarify behavior when rate_limit_count <= 0 and consider avoiding timestamp growth in that case.

With this condition, a non-positive rate_limit_count effectively disables limiting but we still keep pushing timestamps through the queue, incurring overhead for a “disabled” feature. If `rate_limit_count <= 0` is meant to mean “no rate limiting”, consider short‑circuiting before appending, or otherwise avoiding use of the shared queue so we don’t maintain unnecessary timestamp state.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[gemini-code-assist]

Code Review

This pull request modifies the rate-limiting logic in stage.py to handle cases where the rate limit count is zero or less, effectively disabling the limit. A review comment suggests optimizing this implementation by exiting early when rate limiting is disabled to avoid unnecessary memory and CPU overhead from tracking and cleaning up timestamps.

[Copilot]

Pull request overview

Fixes a crash in the pipeline rate-limit stage when the configured rate-limit message count is set to 0 (intended to disable rate limiting), aligning runtime behavior with configuration expectations.

Changes:

• Treat rate_limit_count <= 0 as “rate limiting disabled” to avoid falling through to timestamps[0] access on an empty deque.
• Prevent IndexError: deque index out of range during message processing when rate limiting is disabled.