docs(bench): §9.23 asserting soak — enact rfc 0034 d1 recast, rfc 0035 green - #580
Conversation
…5 green Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WQY9wfrfRggqSpMLH8Xj3Y
|
Warning Review limit reached
Next review available in: 43 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 (3)
📝 WalkthroughWalkthroughThe changes recast D1 as a per-node throughput requirement, add an asserting soak record, and update RFC 0034 and RFC 0035 documentation to reflect enacted criteria, resolved questions, and green Design A status. ChangesD1 benchmark and RFC status documentation
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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
Updates the RFC/benchmark documentation to record the results of the §9.23 asserting soak and to reflect RFC 0034’s D1 recast and RFC 0035 meeting its acceptance criteria.
Changes:
- Marks RFC 0035 as
greenand adds a status note tying its criteria to the in-repo suites and the §9.23 soak evidence. - Adds a status note to RFC 0034 documenting enactment/satisfaction state and resolves related open questions as completed.
- Recasts
docs/benchmarks.mdD1 as a per-node bar (with per-core/ceiling retained as diagnostics) and adds the §9.23 results record.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| docs/rfcs/0035-ingest-concurrency.md | Updates RFC 0035 status to green, adds status note, and checks off the prototype measurement open question. |
| docs/rfcs/0034-d1-rescope.md | Adds a status note documenting RFC0034.1 enactment and RFC0034.2 satisfaction; updates open-questions checklist. |
| docs/benchmarks.md | Recasts D1 per-node with diagnostics retained; adds §9.23 authoritative asserting-soak results. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@docs/benchmarks.md`:
- Around line 326-332: Update the D1 benchmark acceptance wording in
docs/benchmarks.md to make the 100,000 lines/s requirement consistent with
§9.23: state that the run offers 100,000 lines/s and passes when achieved
throughput is at least 99% of offered, while preserving the existing latency
requirement and below-saturation qualification. Apply the same correction to the
corresponding acceptance text near §9.23.
In `@docs/rfcs/0035-ingest-concurrency.md`:
- Around line 361-364: Update the §6 measurement statement in the checklist to
limit the §9.22 result to clearing the red-stage throughput/capacity gate; do
not claim it cleared the full D1 must-win because its p99 latency criterion was
not established. If supported by the surrounding document, cite §9.23 for the
complete D1 result while preserving the benchmark figures.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 2717d0a0-0395-4c5c-ba0d-d8bb3b97ef32
📒 Files selected for processing (3)
docs/benchmarks.mddocs/rfcs/0034-d1-rescope.mddocs/rfcs/0035-ingest-concurrency.md
…ote, §9.22 scope Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WQY9wfrfRggqSpMLH8Xj3Y
…aude.md §3.7 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WQY9wfrfRggqSpMLH8Xj3Y
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
docs/benchmarks.md:313
- The recast note claims the architecture “deliberately serializes” due to “per-tenant miner order” and cites
CLAUDE.md§3.7, but §3.7 only states per-tenant scoping (template trees scoped per tenant) and does not describe an ordering/serialization requirement. This makes the rationale/citation inaccurate. Consider referencing the actual determinism / WAL-order-replay constraint (e.g., RFC 0001 §3.5.3) and keepCLAUDE.md§3.7 for scoping only.
> deliberately serializes twice (sequential per-tenant mining — the
> `CLAUDE.md` §3.7-scoped trees assign ids first-seen, which must
What
The D1-arc closing set, on the §9.23 asserting run's evidence:
baseline-8vcpu-32gib): the RFC0034.2 / RFC0035.4 asserting soak — one hour,--tenants 8, offered exactly 100k lines/s → achieved 99,921 lines/s (99.92% of offered — the observable below-saturation condition ✓), ack p99 153.63 ms ≤ 200 ms ✓, D2 PASS (480 compactions, final backlog 0), 359,726,000 lines acked, 0 failed batches. The harness's printed per-core "FAIL" is the pre-recast bar, recorded as the diagnostic it now is.benchmarks.md§ D1 block is recast per-node (RFC 0011 A1 annotation pattern), old per-core target + per-tenant ceiling retained as diagnostics, falsifier verbatim. (The §7 table lists only the five[THESIS]goals, so the annotation lives at the block — recorded in RFC 0034's status note.)green: .1/.2/.3/.5 via the feat(ingester): rfc 0035 — ordered/concurrent ingest split (production) #577/fix(ingester): rfc 0035 review fixes — capture-slot unwind safety, honest barrier docs #579 suites, .4 via §9.23; ingest: rotation high-water can stamp over the age-sweep's in-flight publish (acked-data loss window, pre-existing) #578 flagged as the known open hazard outside scope.specified— theacceptedflip is the maintainer's.Doc-only; mdbook verified.
🤖 Generated with Claude Code
https://claude.ai/code/session_01WQY9wfrfRggqSpMLH8Xj3Y
Summary by CodeRabbit