feat: HV-2 scheduling driver + native admission telemetry endpoint - #88
Conversation
Adds Tools/Hv2SchedulingRunner for HV-2 (docs/ NATIVE_RUNTIME_HIVE_VALIDATION_PLAN.md): proves capability/resource- aware scheduling across the fleet. Since NativeContextSize is a per-worker-process startup config rather than a per-job HIVE parameter, the two HV-2 checks (large-context denial on the low-VRAM box, small-context admission everywhere) run as two separate fleet configurations of the same three machines against the same driver, using --phase large|small. Also exposes RuntimeReservationSnapshot (RejectedAdmissionCount, LastRejectionReason, Total/Reserved/AvailableBytes) over a new GET /hive/native-telemetry endpoint on HiveNodeServer, wired from HiveService.cs after building the native runtime. This telemetry existed in-process but had no remote observability surface on a headless worker -- only the Avalonia GUI's diagnostics panel could see it. Unauthenticated read-only, same posture as the existing /hive/info endpoint. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@coderabbitai full review |
✅ Action performedFull review finished. Your plan includes PR reviews subject to rate limits. More reviews will be available in 59 minutes. |
|
Warning Review limit reached
Next review available in: 55 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughAdds native admission telemetry exposure to Hive nodes and introduces an HV-2 scheduling runner that dispatches native work, polls outcomes, verifies denial telemetry, and writes JSON evidence reports. ChangesNative telemetry verification
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Runner
participant Warchief
participant WorkerNode
participant EvidenceFile
Runner->>WorkerNode: Fetch baseline NativeTelemetry
Runner->>Warchief: Submit native Hive campaign
Warchief->>WorkerNode: Dispatch native work unit
WorkerNode-->>Warchief: Return task status
Runner->>Warchief: Poll task status
Runner->>WorkerNode: Fetch post-dispatch NativeTelemetry
Runner->>EvidenceFile: Write Hv2Report JSON
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 `@Tools/Hv2SchedulingRunner/Program.cs`:
- Around line 46-58: Validate the --phase large configuration in the worker
setup around GetArg and the workers list: require --low-vram-worker to be
provided and match one of the configured worker IDs, otherwise throw an
InvalidOperationException before running jobs. Preserve the existing
ExpectDenied assignment for the matched worker and normal behavior for other
phases.
- Around line 98-101: Replace the suffix-based worker lookup in the foreach over
workUnits with positional pairing to the workers collection, preserving the
one-to-one order established when workUnits was built. Use the paired worker’s
Id and related metadata for task attribution, and remove the ambiguous
workers.First EndsWith lookup.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 4b3d83de-b6eb-44de-ad76-d8cf267fa326
📒 Files selected for processing (4)
OrchestratorIDE.Daemon/HiveService.csOrchestratorIDE/Services/Hive/HiveNodeServer.csTools/Hv2SchedulingRunner/Hv2SchedulingRunner.csprojTools/Hv2SchedulingRunner/Program.cs
…wrapper
Confirmed empirically during real-fleet calibration: a genuine admission
denial with correct numbers ("Requires ~6.8 GB, only 5.6 GB available")
still surfaces as HiveWorkerAgent's generic "native role runtime failed.
Phase 3B does not fall back." wrapper text at the task level -- the
detailed RuntimeAdmissionDeniedException message never reaches
HiveTaskResult.ErrorMsg, only the worker's own local log. Classify
denial by task status alone (this execution kind can structurally never
fall back instead) and let the separate /hive/native-telemetry check
be the authority on whether it was specifically an admission denial
with correct numbers.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
HardcorePC (6GB) denied at ctx=40000 with a real RuntimeAdmissionDeniedException and correct telemetry (RejectedAdmissionCount 3->6, "Requires ~6.8 GB, only 5.6 GB available"), then admitted cleanly at ctx=8192 -- same box, same model, proving denial is footprint-driven not box-driven. HardcoreLaptopMSI (8GB) admitted at both. The 16GB leg (NewcorePC) is blocked on a separate, genuine finding: running the Daemon locally on NewcorePC to add it as a worker regenerated its own HIVE identity (same DPAPI/AES-GCM collision as HV-1, now on the warchief side), and unlike HV-1's workers this can't be re-paired -- the Daemon can never approve incoming pairing by its own design. Filed as an open follow-up rather than worked around. Also documents a driver classification bug found and fixed mid-campaign, and a real inbound- firewall gap worked around via SSH rather than asking to change system settings. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@coderabbitai full review |
✅ Action performedFull review finished. |
…worker Prevents a silent vacuous PASS: without this guard, an omitted or mistyped --low-vram-worker left ExpectDenied false for every worker, so a misconfigured large-context run could report success without ever exercising the admission-denial path it exists to prove. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@coderabbitai full review |
✅ Action performedFull review finished. Your plan includes PR reviews subject to rate limits. More reviews will be available in 55 minutes. |
1 participant
Summary
Tools/Hv2SchedulingRunnerfor HV-2 (docs/NATIVE_RUNTIME_HIVE_VALIDATION_PLAN.md): proves capability/resource-aware scheduling across the fleet — a large-context job denied on the low-VRAM box with a real fail-closed exception, admitted on higher-VRAM boxes, plus the inverse (small-context job admitted everywhere) proving denial is footprint-driven, not box-driven.NativeContextSizeis a per-worker-process startup config, not a per-job HIVE parameter — so the two checks run as two fleet configurations of the same three machines (--phase large|small) rather than two job shapes against one running config.GET /hive/native-telemetryendpoint onHiveNodeServer, wired fromHiveService.cs, exposingRuntimeReservationSnapshot(RejectedAdmissionCount,LastRejectionReason, VRAM totals) — this existed in-process but had no remote observability surface on a headless worker before this. Unauthenticated read-only, same posture as the existing/hive/info.Test plan
dotnet buildon the new tool, main Avalonia project, and Daemon — all green.dotnet test --filter FullyQualifiedName~Hive— 112/112 passing, no regressions.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes