fix(limits): retry_after ceiling capped at window — deterministic on coarse timers (#346)

[Darkest-Teddy]

Problem

check_rate_limit computes the retry hint as int(window - elapsed) + 1 — a broken ceiling. When the rate-limited call shares an identical time.time() value with the first call in the window, elapsed == 0.0 exactly and the hint overshoots to window + 1 (61s for a 60s window). On Windows this happens reliably (the timer ticks every ~15.6 ms, so a tight loop of 6 calls lands on one tick), which:

• violates the (0, window] contract callers surface as Retry-After, and
• makes TestRateLimit::test_sixth_call_returns_retry_after fail out-of-the-box for every Windows contributor (assert 61 <= 60). Linux CI passes only by accident — elapsed there is tiny-but-nonzero, so int(59.999…) + 1 == 60.

Fix

True ceiling semantics, clamped at the window, in both copies of the limiter:

retry=min(window_sec, math.ceil(window_sec- (now-bucket[0])))

• services/request_limits.py (shared limiter behind OCR extraction + Gradescope routes)
• services/flashcard_import_service.py (older twin the shared module's docstring notes should eventually migrate)

The clamp also guards the pathological elapsed < 0 case (clock steps backward between calls).

Tests (TDD — written first, verified failing)

• test_retry_capped_at_window_on_coincident_timestamps (both limiters): freezes time.time so elapsed == 0.0 exactly — deterministic reproduction of the Windows failure on every platform; pins retry == 60. Failed (61) before the fix, passes after.
• test_retry_uses_ceiling_of_remaining_window (both limiters): 0.5s remaining → retry == 1, pinning ceiling semantics against a regression to plain truncation.
• New tests/test_request_limits.py also covers the shared limiter's base contract (allow-up-to-limit, over-limit hint bounds, key isolation, window reset), which previously had no direct unit tests.

Verification

• Affected suites (test_flashcard_import_service, test_request_limits, test_extract_auth_bounds, test_gradescope): 72/72 passed — on the Windows machine where the suite was previously red.
• ruff check clean on all touched files.

Supersedes #347 (same clamp idea, but closed without regression tests; this PR adds the deterministic frozen-time coverage the issue asked for).

Fixes#346

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved rate-limit retry guidance so displayed wait times remain within the configured limit window.
  • Corrected rounding for fractional remaining wait times, providing more accurate retry estimates.
  • Ensured edge cases, including coincident timestamps and near-expired windows, return valid retry values.

• Tests

  • Added coverage for rate-limit boundaries, timing behavior, key isolation, and window resets.

[coderabbitai]

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:35 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b822bd9-4b81-4c35-85d6-9dd7b4d0d7ea

📥 Commits

Reviewing files that changed from the base of the PR and between b0716af and 6731cd7.

📒 Files selected for processing (3)

• backend/services/request_limits.py
• backend/tests/test_flashcard_import_service.py
• backend/tests/test_request_limits.py

📝 Walkthrough

Walkthrough

The rate limiters now calculate retry delays with ceiling semantics and cap them at the configured window. Tests cover coincident timestamps, near-window expiry, reset behavior, limit enforcement, and per-key isolation.

Changes

Rate-limit retry behavior

Layer / File(s)	Summary
Bounded retry calculations backend/services/flashcard_import_service.py, backend/services/request_limits.py	Retry delays use ceiling-based remaining-window calculations capped at the configured rate-limit window.
Retry boundary coverage backend/tests/test_flashcard_import_service.py, backend/tests/test_request_limits.py	Tests validate bounded retry hints, coincident timestamps, near-window expiry, window resets, request limits, and per-key isolation.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• SaplingLearn/Sapling#347: Updates the same rate-limit retry calculation to cap delays at the configured window.

Suggested reviewers:jose-gael-cruz-lopez

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the retry_after ceiling fix and its deterministic timer behavior.
Description check	✅ Passed	The description covers the problem, fix, testing, and issue reference, which is enough despite different headings.
Linked Issues check	✅ Passed	The PR implements the off-by-one retry_after cap and adds frozen-time regression tests requested by #346.
Out of Scope Changes check	✅ Passed	All changes are directly related to the rate-limit retry fix and its regression coverage.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/346-retry-after-ceiling

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	6731cd7	Commit Preview URL Branch Preview URL	Jul 29 2026, 09:10 AM

[Darkest-Teddy]

Problem

check_rate_limit computes the retry hint as int(window - elapsed) + 1 — a broken ceiling. When the rate-limited call shares an identical time.time() value with the first call in the window, elapsed == 0.0 exactly and the hint overshoots to window + 1 (61s for a 60s window). On Windows this happens reliably (the timer ticks every ~15.6 ms, so a tight loop of 6 calls lands on one tick), which:

• violates the (0, window] contract callers surface as Retry-After, and
• makes TestRateLimit::test_sixth_call_returns_retry_after fail out-of-the-box for every Windows contributor (assert 61 <= 60). Linux CI passes only by accident — elapsed there is tiny-but-nonzero, so int(59.999…) + 1 == 60.

Fix

True ceiling semantics, clamped at the window, in both copies of the limiter:

retry=min(window_sec, math.ceil(window_sec- (now-bucket[0])))

• services/request_limits.py (shared limiter behind OCR extraction + Gradescope routes)
• services/flashcard_import_service.py (older twin the shared module's docstring notes should eventually migrate)

The clamp also guards the pathological elapsed < 0 case (clock steps backward between calls).

Tests (TDD — written first, verified failing)

• test_retry_capped_at_window_on_coincident_timestamps (both limiters): freezes time.time so elapsed == 0.0 exactly — deterministic reproduction of the Windows failure on every platform; pins retry == 60. Failed (61) before the fix, passes after.
• test_retry_uses_ceiling_of_remaining_window (both limiters): 0.5s remaining → retry == 1, pinning ceiling semantics against a regression to plain truncation.
• New tests/test_request_limits.py also covers the shared limiter's base contract (allow-up-to-limit, over-limit hint bounds, key isolation, window reset), which previously had no direct unit tests.

Verification

• Affected suites (test_flashcard_import_service, test_request_limits, test_extract_auth_bounds, test_gradescope): 72/72 passed — on the Windows machine where the suite was previously red.
• ruff check clean on all touched files.

Supersedes #347 (same clamp idea, but closed without regression tests; this PR adds the deterministic frozen-time coverage the issue asked for).

Fixes#346

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved rate-limit retry guidance so displayed wait times remain within the configured limit window.
  • Corrected rounding for fractional remaining wait times, providing more accurate retry estimates.
  • Ensured edge cases, including coincident timestamps and near-expired windows, return valid retry values.

• Tests

  • Added coverage for rate-limit boundaries, timing behavior, key isolation, and window resets.

[coderabbitai]

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:35 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b822bd9-4b81-4c35-85d6-9dd7b4d0d7ea

📥 Commits

Reviewing files that changed from the base of the PR and between b0716af and 6731cd7.

📒 Files selected for processing (3)

• backend/services/request_limits.py
• backend/tests/test_flashcard_import_service.py
• backend/tests/test_request_limits.py

📝 Walkthrough

Walkthrough

The rate limiters now calculate retry delays with ceiling semantics and cap them at the configured window. Tests cover coincident timestamps, near-window expiry, reset behavior, limit enforcement, and per-key isolation.

Changes

Rate-limit retry behavior

Layer / File(s)	Summary
Bounded retry calculations backend/services/flashcard_import_service.py, backend/services/request_limits.py	Retry delays use ceiling-based remaining-window calculations capped at the configured rate-limit window.
Retry boundary coverage backend/tests/test_flashcard_import_service.py, backend/tests/test_request_limits.py	Tests validate bounded retry hints, coincident timestamps, near-window expiry, window resets, request limits, and per-key isolation.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• SaplingLearn/Sapling#347: Updates the same rate-limit retry calculation to cap delays at the configured window.

Suggested reviewers:jose-gael-cruz-lopez

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the retry_after ceiling fix and its deterministic timer behavior.
Description check	✅ Passed	The description covers the problem, fix, testing, and issue reference, which is enough despite different headings.
Linked Issues check	✅ Passed	The PR implements the off-by-one retry_after cap and adds frozen-time regression tests requested by #346.
Out of Scope Changes check	✅ Passed	All changes are directly related to the rate-limit retry fix and its regression coverage.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/346-retry-after-ceiling

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	6731cd7	Commit Preview URL Branch Preview URL	Jul 29 2026, 09:10 AM

[Darkest-Teddy]

Problem

check_rate_limit computes the retry hint as int(window - elapsed) + 1 — a broken ceiling. When the rate-limited call shares an identical time.time() value with the first call in the window, elapsed == 0.0 exactly and the hint overshoots to window + 1 (61s for a 60s window). On Windows this happens reliably (the timer ticks every ~15.6 ms, so a tight loop of 6 calls lands on one tick), which:

• violates the (0, window] contract callers surface as Retry-After, and
• makes TestRateLimit::test_sixth_call_returns_retry_after fail out-of-the-box for every Windows contributor (assert 61 <= 60). Linux CI passes only by accident — elapsed there is tiny-but-nonzero, so int(59.999…) + 1 == 60.

Fix

True ceiling semantics, clamped at the window, in both copies of the limiter:

retry=min(window_sec, math.ceil(window_sec- (now-bucket[0])))

• services/request_limits.py (shared limiter behind OCR extraction + Gradescope routes)
• services/flashcard_import_service.py (older twin the shared module's docstring notes should eventually migrate)

The clamp also guards the pathological elapsed < 0 case (clock steps backward between calls).

Tests (TDD — written first, verified failing)

• test_retry_capped_at_window_on_coincident_timestamps (both limiters): freezes time.time so elapsed == 0.0 exactly — deterministic reproduction of the Windows failure on every platform; pins retry == 60. Failed (61) before the fix, passes after.
• test_retry_uses_ceiling_of_remaining_window (both limiters): 0.5s remaining → retry == 1, pinning ceiling semantics against a regression to plain truncation.
• New tests/test_request_limits.py also covers the shared limiter's base contract (allow-up-to-limit, over-limit hint bounds, key isolation, window reset), which previously had no direct unit tests.

Verification

• Affected suites (test_flashcard_import_service, test_request_limits, test_extract_auth_bounds, test_gradescope): 72/72 passed — on the Windows machine where the suite was previously red.
• ruff check clean on all touched files.

Supersedes #347 (same clamp idea, but closed without regression tests; this PR adds the deterministic frozen-time coverage the issue asked for).

Fixes#346

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved rate-limit retry guidance so displayed wait times remain within the configured limit window.
  • Corrected rounding for fractional remaining wait times, providing more accurate retry estimates.
  • Ensured edge cases, including coincident timestamps and near-expired windows, return valid retry values.

• Tests

  • Added coverage for rate-limit boundaries, timing behavior, key isolation, and window resets.

[coderabbitai]

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:35 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b822bd9-4b81-4c35-85d6-9dd7b4d0d7ea

📥 Commits

Reviewing files that changed from the base of the PR and between b0716af and 6731cd7.

📒 Files selected for processing (3)

• backend/services/request_limits.py
• backend/tests/test_flashcard_import_service.py
• backend/tests/test_request_limits.py

📝 Walkthrough

Walkthrough

The rate limiters now calculate retry delays with ceiling semantics and cap them at the configured window. Tests cover coincident timestamps, near-window expiry, reset behavior, limit enforcement, and per-key isolation.

Changes

Rate-limit retry behavior

Layer / File(s)	Summary
Bounded retry calculations backend/services/flashcard_import_service.py, backend/services/request_limits.py	Retry delays use ceiling-based remaining-window calculations capped at the configured rate-limit window.
Retry boundary coverage backend/tests/test_flashcard_import_service.py, backend/tests/test_request_limits.py	Tests validate bounded retry hints, coincident timestamps, near-window expiry, window resets, request limits, and per-key isolation.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• SaplingLearn/Sapling#347: Updates the same rate-limit retry calculation to cap delays at the configured window.

Suggested reviewers:jose-gael-cruz-lopez

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the retry_after ceiling fix and its deterministic timer behavior.
Description check	✅ Passed	The description covers the problem, fix, testing, and issue reference, which is enough despite different headings.
Linked Issues check	✅ Passed	The PR implements the off-by-one retry_after cap and adds frozen-time regression tests requested by #346.
Out of Scope Changes check	✅ Passed	All changes are directly related to the rate-limit retry fix and its regression coverage.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/346-retry-after-ceiling

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	6731cd7	Commit Preview URL Branch Preview URL	Jul 29 2026, 09:10 AM

[Darkest-Teddy]

Problem

check_rate_limit computes the retry hint as int(window - elapsed) + 1 — a broken ceiling. When the rate-limited call shares an identical time.time() value with the first call in the window, elapsed == 0.0 exactly and the hint overshoots to window + 1 (61s for a 60s window). On Windows this happens reliably (the timer ticks every ~15.6 ms, so a tight loop of 6 calls lands on one tick), which:

• violates the (0, window] contract callers surface as Retry-After, and
• makes TestRateLimit::test_sixth_call_returns_retry_after fail out-of-the-box for every Windows contributor (assert 61 <= 60). Linux CI passes only by accident — elapsed there is tiny-but-nonzero, so int(59.999…) + 1 == 60.

Fix

True ceiling semantics, clamped at the window, in both copies of the limiter:

retry=min(window_sec, math.ceil(window_sec- (now-bucket[0])))

• services/request_limits.py (shared limiter behind OCR extraction + Gradescope routes)
• services/flashcard_import_service.py (older twin the shared module's docstring notes should eventually migrate)

The clamp also guards the pathological elapsed < 0 case (clock steps backward between calls).

Tests (TDD — written first, verified failing)

• test_retry_capped_at_window_on_coincident_timestamps (both limiters): freezes time.time so elapsed == 0.0 exactly — deterministic reproduction of the Windows failure on every platform; pins retry == 60. Failed (61) before the fix, passes after.
• test_retry_uses_ceiling_of_remaining_window (both limiters): 0.5s remaining → retry == 1, pinning ceiling semantics against a regression to plain truncation.
• New tests/test_request_limits.py also covers the shared limiter's base contract (allow-up-to-limit, over-limit hint bounds, key isolation, window reset), which previously had no direct unit tests.

Verification

• Affected suites (test_flashcard_import_service, test_request_limits, test_extract_auth_bounds, test_gradescope): 72/72 passed — on the Windows machine where the suite was previously red.
• ruff check clean on all touched files.

Supersedes #347 (same clamp idea, but closed without regression tests; this PR adds the deterministic frozen-time coverage the issue asked for).

Fixes#346

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved rate-limit retry guidance so displayed wait times remain within the configured limit window.
  • Corrected rounding for fractional remaining wait times, providing more accurate retry estimates.
  • Ensured edge cases, including coincident timestamps and near-expired windows, return valid retry values.

• Tests

  • Added coverage for rate-limit boundaries, timing behavior, key isolation, and window resets.

[coderabbitai]

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:35 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b822bd9-4b81-4c35-85d6-9dd7b4d0d7ea

📥 Commits

Reviewing files that changed from the base of the PR and between b0716af and 6731cd7.

📒 Files selected for processing (3)

• backend/services/request_limits.py
• backend/tests/test_flashcard_import_service.py
• backend/tests/test_request_limits.py

📝 Walkthrough

Walkthrough

The rate limiters now calculate retry delays with ceiling semantics and cap them at the configured window. Tests cover coincident timestamps, near-window expiry, reset behavior, limit enforcement, and per-key isolation.

Changes

Rate-limit retry behavior

Layer / File(s)	Summary
Bounded retry calculations backend/services/flashcard_import_service.py, backend/services/request_limits.py	Retry delays use ceiling-based remaining-window calculations capped at the configured rate-limit window.
Retry boundary coverage backend/tests/test_flashcard_import_service.py, backend/tests/test_request_limits.py	Tests validate bounded retry hints, coincident timestamps, near-window expiry, window resets, request limits, and per-key isolation.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• SaplingLearn/Sapling#347: Updates the same rate-limit retry calculation to cap delays at the configured window.

Suggested reviewers:jose-gael-cruz-lopez

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the retry_after ceiling fix and its deterministic timer behavior.
Description check	✅ Passed	The description covers the problem, fix, testing, and issue reference, which is enough despite different headings.
Linked Issues check	✅ Passed	The PR implements the off-by-one retry_after cap and adds frozen-time regression tests requested by #346.
Out of Scope Changes check	✅ Passed	All changes are directly related to the rate-limit retry fix and its regression coverage.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/346-retry-after-ceiling

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	6731cd7	Commit Preview URL Branch Preview URL	Jul 29 2026, 09:10 AM

[Darkest-Teddy]

Problem

check_rate_limit computes the retry hint as int(window - elapsed) + 1 — a broken ceiling. When the rate-limited call shares an identical time.time() value with the first call in the window, elapsed == 0.0 exactly and the hint overshoots to window + 1 (61s for a 60s window). On Windows this happens reliably (the timer ticks every ~15.6 ms, so a tight loop of 6 calls lands on one tick), which:

• violates the (0, window] contract callers surface as Retry-After, and
• makes TestRateLimit::test_sixth_call_returns_retry_after fail out-of-the-box for every Windows contributor (assert 61 <= 60). Linux CI passes only by accident — elapsed there is tiny-but-nonzero, so int(59.999…) + 1 == 60.

Fix

True ceiling semantics, clamped at the window, in both copies of the limiter:

retry=min(window_sec, math.ceil(window_sec- (now-bucket[0])))

• services/request_limits.py (shared limiter behind OCR extraction + Gradescope routes)
• services/flashcard_import_service.py (older twin the shared module's docstring notes should eventually migrate)

The clamp also guards the pathological elapsed < 0 case (clock steps backward between calls).

Tests (TDD — written first, verified failing)

• test_retry_capped_at_window_on_coincident_timestamps (both limiters): freezes time.time so elapsed == 0.0 exactly — deterministic reproduction of the Windows failure on every platform; pins retry == 60. Failed (61) before the fix, passes after.
• test_retry_uses_ceiling_of_remaining_window (both limiters): 0.5s remaining → retry == 1, pinning ceiling semantics against a regression to plain truncation.
• New tests/test_request_limits.py also covers the shared limiter's base contract (allow-up-to-limit, over-limit hint bounds, key isolation, window reset), which previously had no direct unit tests.

Verification

• Affected suites (test_flashcard_import_service, test_request_limits, test_extract_auth_bounds, test_gradescope): 72/72 passed — on the Windows machine where the suite was previously red.
• ruff check clean on all touched files.

Supersedes #347 (same clamp idea, but closed without regression tests; this PR adds the deterministic frozen-time coverage the issue asked for).

Fixes#346

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved rate-limit retry guidance so displayed wait times remain within the configured limit window.
  • Corrected rounding for fractional remaining wait times, providing more accurate retry estimates.
  • Ensured edge cases, including coincident timestamps and near-expired windows, return valid retry values.

• Tests

  • Added coverage for rate-limit boundaries, timing behavior, key isolation, and window resets.

[coderabbitai]

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:35 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b822bd9-4b81-4c35-85d6-9dd7b4d0d7ea

📥 Commits

Reviewing files that changed from the base of the PR and between b0716af and 6731cd7.

📒 Files selected for processing (3)

• backend/services/request_limits.py
• backend/tests/test_flashcard_import_service.py
• backend/tests/test_request_limits.py

📝 Walkthrough

Walkthrough

The rate limiters now calculate retry delays with ceiling semantics and cap them at the configured window. Tests cover coincident timestamps, near-window expiry, reset behavior, limit enforcement, and per-key isolation.

Changes

Rate-limit retry behavior

Layer / File(s)	Summary
Bounded retry calculations backend/services/flashcard_import_service.py, backend/services/request_limits.py	Retry delays use ceiling-based remaining-window calculations capped at the configured rate-limit window.
Retry boundary coverage backend/tests/test_flashcard_import_service.py, backend/tests/test_request_limits.py	Tests validate bounded retry hints, coincident timestamps, near-window expiry, window resets, request limits, and per-key isolation.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• SaplingLearn/Sapling#347: Updates the same rate-limit retry calculation to cap delays at the configured window.

Suggested reviewers:jose-gael-cruz-lopez

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the retry_after ceiling fix and its deterministic timer behavior.
Description check	✅ Passed	The description covers the problem, fix, testing, and issue reference, which is enough despite different headings.
Linked Issues check	✅ Passed	The PR implements the off-by-one retry_after cap and adds frozen-time regression tests requested by #346.
Out of Scope Changes check	✅ Passed	All changes are directly related to the rate-limit retry fix and its regression coverage.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/346-retry-after-ceiling

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	6731cd7	Commit Preview URL Branch Preview URL	Jul 29 2026, 09:10 AM

[Darkest-Teddy]

Problem

check_rate_limit computes the retry hint as int(window - elapsed) + 1 — a broken ceiling. When the rate-limited call shares an identical time.time() value with the first call in the window, elapsed == 0.0 exactly and the hint overshoots to window + 1 (61s for a 60s window). On Windows this happens reliably (the timer ticks every ~15.6 ms, so a tight loop of 6 calls lands on one tick), which:

• violates the (0, window] contract callers surface as Retry-After, and
• makes TestRateLimit::test_sixth_call_returns_retry_after fail out-of-the-box for every Windows contributor (assert 61 <= 60). Linux CI passes only by accident — elapsed there is tiny-but-nonzero, so int(59.999…) + 1 == 60.

Fix

True ceiling semantics, clamped at the window, in both copies of the limiter:

retry=min(window_sec, math.ceil(window_sec- (now-bucket[0])))

• services/request_limits.py (shared limiter behind OCR extraction + Gradescope routes)
• services/flashcard_import_service.py (older twin the shared module's docstring notes should eventually migrate)

The clamp also guards the pathological elapsed < 0 case (clock steps backward between calls).

Tests (TDD — written first, verified failing)

• test_retry_capped_at_window_on_coincident_timestamps (both limiters): freezes time.time so elapsed == 0.0 exactly — deterministic reproduction of the Windows failure on every platform; pins retry == 60. Failed (61) before the fix, passes after.
• test_retry_uses_ceiling_of_remaining_window (both limiters): 0.5s remaining → retry == 1, pinning ceiling semantics against a regression to plain truncation.
• New tests/test_request_limits.py also covers the shared limiter's base contract (allow-up-to-limit, over-limit hint bounds, key isolation, window reset), which previously had no direct unit tests.

Verification

• Affected suites (test_flashcard_import_service, test_request_limits, test_extract_auth_bounds, test_gradescope): 72/72 passed — on the Windows machine where the suite was previously red.
• ruff check clean on all touched files.

Supersedes #347 (same clamp idea, but closed without regression tests; this PR adds the deterministic frozen-time coverage the issue asked for).

Fixes#346

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved rate-limit retry guidance so displayed wait times remain within the configured limit window.
  • Corrected rounding for fractional remaining wait times, providing more accurate retry estimates.
  • Ensured edge cases, including coincident timestamps and near-expired windows, return valid retry values.

• Tests

  • Added coverage for rate-limit boundaries, timing behavior, key isolation, and window resets.

[coderabbitai]

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:35 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b822bd9-4b81-4c35-85d6-9dd7b4d0d7ea

📥 Commits

Reviewing files that changed from the base of the PR and between b0716af and 6731cd7.

📒 Files selected for processing (3)

• backend/services/request_limits.py
• backend/tests/test_flashcard_import_service.py
• backend/tests/test_request_limits.py

📝 Walkthrough

Walkthrough

The rate limiters now calculate retry delays with ceiling semantics and cap them at the configured window. Tests cover coincident timestamps, near-window expiry, reset behavior, limit enforcement, and per-key isolation.

Changes

Rate-limit retry behavior

Layer / File(s)	Summary
Bounded retry calculations backend/services/flashcard_import_service.py, backend/services/request_limits.py	Retry delays use ceiling-based remaining-window calculations capped at the configured rate-limit window.
Retry boundary coverage backend/tests/test_flashcard_import_service.py, backend/tests/test_request_limits.py	Tests validate bounded retry hints, coincident timestamps, near-window expiry, window resets, request limits, and per-key isolation.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• SaplingLearn/Sapling#347: Updates the same rate-limit retry calculation to cap delays at the configured window.

Suggested reviewers:jose-gael-cruz-lopez

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the retry_after ceiling fix and its deterministic timer behavior.
Description check	✅ Passed	The description covers the problem, fix, testing, and issue reference, which is enough despite different headings.
Linked Issues check	✅ Passed	The PR implements the off-by-one retry_after cap and adds frozen-time regression tests requested by #346.
Out of Scope Changes check	✅ Passed	All changes are directly related to the rate-limit retry fix and its regression coverage.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/346-retry-after-ceiling

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	6731cd7	Commit Preview URL Branch Preview URL	Jul 29 2026, 09:10 AM

[Darkest-Teddy]

Problem

check_rate_limit computes the retry hint as int(window - elapsed) + 1 — a broken ceiling. When the rate-limited call shares an identical time.time() value with the first call in the window, elapsed == 0.0 exactly and the hint overshoots to window + 1 (61s for a 60s window). On Windows this happens reliably (the timer ticks every ~15.6 ms, so a tight loop of 6 calls lands on one tick), which:

• violates the (0, window] contract callers surface as Retry-After, and
• makes TestRateLimit::test_sixth_call_returns_retry_after fail out-of-the-box for every Windows contributor (assert 61 <= 60). Linux CI passes only by accident — elapsed there is tiny-but-nonzero, so int(59.999…) + 1 == 60.

Fix

True ceiling semantics, clamped at the window, in both copies of the limiter:

retry=min(window_sec, math.ceil(window_sec- (now-bucket[0])))

• services/request_limits.py (shared limiter behind OCR extraction + Gradescope routes)
• services/flashcard_import_service.py (older twin the shared module's docstring notes should eventually migrate)

The clamp also guards the pathological elapsed < 0 case (clock steps backward between calls).

Tests (TDD — written first, verified failing)

• test_retry_capped_at_window_on_coincident_timestamps (both limiters): freezes time.time so elapsed == 0.0 exactly — deterministic reproduction of the Windows failure on every platform; pins retry == 60. Failed (61) before the fix, passes after.
• test_retry_uses_ceiling_of_remaining_window (both limiters): 0.5s remaining → retry == 1, pinning ceiling semantics against a regression to plain truncation.
• New tests/test_request_limits.py also covers the shared limiter's base contract (allow-up-to-limit, over-limit hint bounds, key isolation, window reset), which previously had no direct unit tests.

Verification

• Affected suites (test_flashcard_import_service, test_request_limits, test_extract_auth_bounds, test_gradescope): 72/72 passed — on the Windows machine where the suite was previously red.
• ruff check clean on all touched files.

Supersedes #347 (same clamp idea, but closed without regression tests; this PR adds the deterministic frozen-time coverage the issue asked for).

Fixes#346

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved rate-limit retry guidance so displayed wait times remain within the configured limit window.
  • Corrected rounding for fractional remaining wait times, providing more accurate retry estimates.
  • Ensured edge cases, including coincident timestamps and near-expired windows, return valid retry values.

• Tests

  • Added coverage for rate-limit boundaries, timing behavior, key isolation, and window resets.

[coderabbitai]

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:35 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b822bd9-4b81-4c35-85d6-9dd7b4d0d7ea

📥 Commits

Reviewing files that changed from the base of the PR and between b0716af and 6731cd7.

📒 Files selected for processing (3)

• backend/services/request_limits.py
• backend/tests/test_flashcard_import_service.py
• backend/tests/test_request_limits.py

📝 Walkthrough

Walkthrough

The rate limiters now calculate retry delays with ceiling semantics and cap them at the configured window. Tests cover coincident timestamps, near-window expiry, reset behavior, limit enforcement, and per-key isolation.

Changes

Rate-limit retry behavior

Layer / File(s)	Summary
Bounded retry calculations backend/services/flashcard_import_service.py, backend/services/request_limits.py	Retry delays use ceiling-based remaining-window calculations capped at the configured rate-limit window.
Retry boundary coverage backend/tests/test_flashcard_import_service.py, backend/tests/test_request_limits.py	Tests validate bounded retry hints, coincident timestamps, near-window expiry, window resets, request limits, and per-key isolation.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• SaplingLearn/Sapling#347: Updates the same rate-limit retry calculation to cap delays at the configured window.

Suggested reviewers:jose-gael-cruz-lopez

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the retry_after ceiling fix and its deterministic timer behavior.
Description check	✅ Passed	The description covers the problem, fix, testing, and issue reference, which is enough despite different headings.
Linked Issues check	✅ Passed	The PR implements the off-by-one retry_after cap and adds frozen-time regression tests requested by #346.
Out of Scope Changes check	✅ Passed	All changes are directly related to the rate-limit retry fix and its regression coverage.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/346-retry-after-ceiling

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	6731cd7	Commit Preview URL Branch Preview URL	Jul 29 2026, 09:10 AM

[Darkest-Teddy]

Problem

check_rate_limit computes the retry hint as int(window - elapsed) + 1 — a broken ceiling. When the rate-limited call shares an identical time.time() value with the first call in the window, elapsed == 0.0 exactly and the hint overshoots to window + 1 (61s for a 60s window). On Windows this happens reliably (the timer ticks every ~15.6 ms, so a tight loop of 6 calls lands on one tick), which:

• violates the (0, window] contract callers surface as Retry-After, and
• makes TestRateLimit::test_sixth_call_returns_retry_after fail out-of-the-box for every Windows contributor (assert 61 <= 60). Linux CI passes only by accident — elapsed there is tiny-but-nonzero, so int(59.999…) + 1 == 60.

Fix

True ceiling semantics, clamped at the window, in both copies of the limiter:

retry=min(window_sec, math.ceil(window_sec- (now-bucket[0])))

• services/request_limits.py (shared limiter behind OCR extraction + Gradescope routes)
• services/flashcard_import_service.py (older twin the shared module's docstring notes should eventually migrate)

The clamp also guards the pathological elapsed < 0 case (clock steps backward between calls).

Tests (TDD — written first, verified failing)

• test_retry_capped_at_window_on_coincident_timestamps (both limiters): freezes time.time so elapsed == 0.0 exactly — deterministic reproduction of the Windows failure on every platform; pins retry == 60. Failed (61) before the fix, passes after.
• test_retry_uses_ceiling_of_remaining_window (both limiters): 0.5s remaining → retry == 1, pinning ceiling semantics against a regression to plain truncation.
• New tests/test_request_limits.py also covers the shared limiter's base contract (allow-up-to-limit, over-limit hint bounds, key isolation, window reset), which previously had no direct unit tests.

Verification

• Affected suites (test_flashcard_import_service, test_request_limits, test_extract_auth_bounds, test_gradescope): 72/72 passed — on the Windows machine where the suite was previously red.
• ruff check clean on all touched files.

Supersedes #347 (same clamp idea, but closed without regression tests; this PR adds the deterministic frozen-time coverage the issue asked for).

Fixes#346

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Improved rate-limit retry guidance so displayed wait times remain within the configured limit window.
  • Corrected rounding for fractional remaining wait times, providing more accurate retry estimates.
  • Ensured edge cases, including coincident timestamps and near-expired windows, return valid retry values.

• Tests

  • Added coverage for rate-limit boundaries, timing behavior, key isolation, and window resets.

[coderabbitai]

Warning

Review limit reached

@AndresL230, you've reached your PR review limit, so we couldn't start this review.

Next review available in:35 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0b822bd9-4b81-4c35-85d6-9dd7b4d0d7ea

📥 Commits

Reviewing files that changed from the base of the PR and between b0716af and 6731cd7.

📒 Files selected for processing (3)

• backend/services/request_limits.py
• backend/tests/test_flashcard_import_service.py
• backend/tests/test_request_limits.py

📝 Walkthrough

Walkthrough

The rate limiters now calculate retry delays with ceiling semantics and cap them at the configured window. Tests cover coincident timestamps, near-window expiry, reset behavior, limit enforcement, and per-key isolation.

Changes

Rate-limit retry behavior

Layer / File(s)	Summary
Bounded retry calculations backend/services/flashcard_import_service.py, backend/services/request_limits.py	Retry delays use ceiling-based remaining-window calculations capped at the configured rate-limit window.
Retry boundary coverage backend/tests/test_flashcard_import_service.py, backend/tests/test_request_limits.py	Tests validate bounded retry hints, coincident timestamps, near-window expiry, window resets, request limits, and per-key isolation.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• SaplingLearn/Sapling#347: Updates the same rate-limit retry calculation to cap delays at the configured window.

Suggested reviewers:jose-gael-cruz-lopez

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the retry_after ceiling fix and its deterministic timer behavior.
Description check	✅ Passed	The description covers the problem, fix, testing, and issue reference, which is enough despite different headings.
Linked Issues check	✅ Passed	The PR implements the off-by-one retry_after cap and adds frozen-time regression tests requested by #346.
Out of Scope Changes check	✅ Passed	All changes are directly related to the rate-limit retry fix and its regression coverage.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/346-retry-after-ceiling

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	6731cd7	Commit Preview URL Branch Preview URL	Jul 29 2026, 09:10 AM