Reduce Redis block wait scan pressure#1139
Conversation
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
Warning Review limit reached
Next review available in: 53 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughRedisブロッキングコマンドのフォールバック待機間隔をRedisServerごとに設定可能にし、XREAD・BZPOPMINの待機処理へ伝播させた。既定値と不正値の扱いを追加し、テスト設定および関連コメントを更新した。 ChangesRedisブロック待機フォールバック
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant RedisServer
participant bzpopminWaitLoop
participant waitForBlockedCommandUpdate
participant BLOCKDeadline
RedisServer->>bzpopminWaitLoop: blockWaitFallback
bzpopminWaitLoop->>waitForBlockedCommandUpdate: fallbackInterval
waitForBlockedCommandUpdate->>BLOCKDeadline: 残り時間で上限調整
waitForBlockedCommandUpdate-->>bzpopminWaitLoop: 待機結果
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6edca89733
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // only a safety net for missed signals, wrong-type detection, and the | ||
| // BLOCK deadline. Keep it coarse enough that many idle blocking commands | ||
| // do not turn into a constant stream of full key-type scans. | ||
| redisBlockWaitFallback = time.Second |
There was a problem hiding this comment.
For waiters that depend on the fallback rather than an in-process Signal (for example Lua XADD in the default NewRedisServer/test wiring, or any direct mutation path this safety net is meant to cover), raising this to 1s makes any sub-second BLOCK sleep until its deadline because waitForBlockedCommandUpdate caps the timer to the remaining block window. xreadBusyPoll then checks iterTimeout <= 0 before running another xreadOnce, so an entry committed during a 500ms XREAD BLOCK can still return redis.Nil instead of the new stream entry. Consider keeping the fallback below common sub-second block budgets or making every bypass path signal the waiter.
Useful? React with 👍 / 👎.
| // only a safety net for missed signals, wrong-type detection, and the | ||
| // BLOCK deadline. Keep it coarse enough that many idle blocking commands | ||
| // do not turn into a constant stream of full key-type scans. | ||
| redisBlockWaitFallback = time.Second |
There was a problem hiding this comment.
When a multi-key BZPOPMIN is kept awake by fast zset signals on one key, bzpopminWaitLoop uses this same interval as the maximum time it may keep calling keyTypeAtExpectFast and skipping wrong-type detection. With the interval now at 1s, a sub-second block such as 500ms can time out with redis.Nil if another registered key is changed to a string during the wait, because the forced full probe is not re-armed before the deadline; keeping the wrong-type full-check cadence separate from the coarse idle fallback would preserve the existing WRONGTYPE behavior without restoring every idle scan.
Useful? React with 👍 / 👎.
|
@codex review |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
adapter/redis.go (1)
343-350: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win設定オプションの契約をテーブル駆動テストで固定してください。
既定値、正値による上書き、
0・負値では既定値を維持する挙動は、新しい公開オプションの重要な契約です。*_test.goに境界値を含むテーブル駆動テストを追加してください。As per coding guidelines、Goの単体テストは
*_test.goに同居させ、テーブル駆動テストを優先してください。🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@adapter/redis.go` around lines 343 - 350, Add a table-driven unit test in a *_test.go file for WithRedisBlockWaitFallback, covering the default value, a positive duration override, zero, and negative durations. Apply each option to a RedisServer and assert that positive input changes blockWaitFallback while zero and negative input preserve the default.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@adapter/redis_bzpopmin_wake_test.go`:
- Around line 177-180: Remove the unmatched closing parenthesis from the comment
in the wake-loop test, changing “previous one)” to “previous one” while leaving
the test logic unchanged.
---
Nitpick comments:
In `@adapter/redis.go`:
- Around line 343-350: Add a table-driven unit test in a *_test.go file for
WithRedisBlockWaitFallback, covering the default value, a positive duration
override, zero, and negative durations. Apply each option to a RedisServer and
assert that positive input changes blockWaitFallback while zero and negative
input preserve the default.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6923d43c-3859-4c17-b7a1-3be152fd13c1
📒 Files selected for processing (9)
adapter/redis.goadapter/redis_bzpopmin_wake_test.goadapter/redis_compat_commands.goadapter/redis_compat_commands_stream_test.goadapter/redis_compat_helpers.goadapter/redis_key_waiters_test.goadapter/redis_stream_cmds.goadapter/redis_zset_cmds.goadapter/test_util.go
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Summary
Runtime evidence
Validation
Author: bootjp
Summary by CodeRabbit
新機能
改善