fix(bench): RFC 0031 — raise Loki's internal gRPC cap (single-line inflation) - #478
Conversation
#4) Run #4 (29165198664) failed on the SAME ~5.27 MB internal message as runs #2/#3 despite the outer cap halving (3 MiB → 1.5 MB), and the fail-fast stayed silent — decisive: a single kafka LogsData line's content alone inflates past Loki's stock 4 MiB internal gRPC cap. No outer batching can split an indivisible unit. Add -server.grpc-server-max-recv/send-msg-size=16 MiB to the indicative run's documented ingest-side flags (standard operator tuning, in Loki's favour — it lets Loki accept the data at all). This preserves the identical-ingest precondition the equivalence check requires; skipping the line would silently unequalize the two corpora. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 18 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: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
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.
Pull request overview
This PR updates the RFC 0031 comparative Loki benchmark harness to document and apply an increased internal Loki gRPC message-size limit, addressing failures caused by a single indivisible LogsData line inflating beyond Loki’s default 4 MiB internal cap during OTLP→logproto translation.
Changes:
- Adds Loki CLI flags intended to raise the internal gRPC max receive/send message sizes to 16 MiB for the indicative comparative run.
- Documents the multi-run diagnosis rationale inline next to the Loki container flags.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Copilot caught that the flags are -server.grpc-max-recv/send-msg-size- bytes (dskit's server registry, defaults exactly the 4 MiB we hit), not -server.grpc-server-max-*. The wrong names would have failed Loki's startup and burned run #5. Verified against dskit source. Also backtick the kafka service name in the comment. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
What
Run #4 (29165198664) produced the decisive data point: it failed on the same ~5.27 MB internal message as runs #2/#3 despite the outer batch cap halving (3 MiB → 1.5 MB), with the payload fail-fast staying silent. Conclusion: a single kafka
LogsDataline's content alone inflates past Loki's stock 4 MiB internal gRPC cap in the OTLP→logproto translation. No outer batching can split an indivisible unit.Fix
Add
-server.grpc-server-max-recv/send-msg-size=16 MiBto the indicative run's documented ingest-side flags. This is the honest option:The 1.5 MB outer cap and the payload fail-fast stay — they're correct client behaviour regardless.
The three-run diagnosis chain
#2: count-capped 500-line batch encoded >4 MiB → byte cap. #3: same internal size at ≤3 MiB outer, fail-fast silent → inflation, not our payload. #4: same internal size at ≤1.5 MB outer → a single indivisible line, not uniform inflation. Each guard added along the way is what made the next diagnosis unambiguous.
After merge
Re-dispatch → run #5. The mega-line region should now clear; beyond it lies the untested back half of the replay, at-scale equivalence, and the report.
🤖 Generated with Claude Code