fix: reconcile the DHCP replies-sent counter's HELP across its two crates#3466
Conversation
…ates `carbide_dhcp_replies_sent_total` is emitted by two separate binaries -- the DHCP relay in `crates/dhcp` and the standalone DHCP server in `crates/dhcp-server` -- which declared it with divergent HELP text. `dhcp` describes it as "Number of DHCP replies sent, by reply message type."; `dhcp-server` said "Number of DHCP replies successfully sent, by reply message type." Same metric, same meaning, two strings, so a scraper sees inconsistent HELP depending on which process it hits, and a catalogue built by scanning declarations would face an ambiguous entry. The two are the same metric legitimately exported by two processes, so the fix is to unify the description, not to rename. `dhcp-server`'s "successfully" is redundant -- packets that never receive a reply are counted separately under its own drop counter -- so this aligns `dhcp-server` on `dhcp`'s shorter wording. - `crates/dhcp-server/src/metrics.rs`: drop "successfully" from the `replies_sent` describe so both crates declare identical HELP. The counter isn't exercised by `test_integration`, so it isn't in `core_metrics.md` today and there's no catalogue regen here; when the instrumentation doc-gate documents it, the reconciled HELP is what it will record. This supports NVIDIA#3461 Signed-off-by: Chet Nichols III <chetn@nvidia.com>
|
@coderabbitai full_review, thanks! |
|
ᕦ(ò_óˇ)ᕤ ✅ Action performedFull review finished. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
Summary by CodeRabbit
WalkthroughThe DHCP reply metric description now refers to replies sent by message type without stating that they were successfully sent. No metric logic, labels, or event fields changed. ChangesDHCP metrics
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
🔍 Container Scan Summary
Per-CVE detail lives in the per-service |
carbide_dhcp_replies_sent_totalis emitted by two separate binaries -- the DHCP relay incrates/dhcpand the standalone DHCP server incrates/dhcp-server-- which declared it with divergent HELP text ("replies sent" vs "replies successfully sent"). Same metric, same meaning, two strings, so a scraper sees inconsistent HELP depending on which process it hits.The two are the same metric legitimately exported by two processes, so this unifies the description rather than renaming:
dhcp-server's "successfully" is redundant (packets that never get a reply are counted separately under its own drop counter), so it now matchesdhcp's shorter wording.crates/dhcp-server/src/metrics.rs: drop "successfully" from thereplies_sentdescribe so both crates declare identical HELP.The counter isn't exercised by
test_integration, so it isn't incore_metrics.mdtoday and there's no catalogue regen here. When #3463's doc-gate documents it, the reconciled HELP is what it will record; if #3463 lands first, this rebases so the catalogue row reads "sent".This supports #3461