vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

cut the comments back to what the code cannot say

Browse source 
mara: comments to code ratio too high. It was 16 comment lines for one
line of feature.

Kept only the fact that stops the feature being trimmed away again - it
is not a transport, it is in `default`, so `default-features = false`
drops it - and, in hive-metric, the one reason its declaration
deliberately differs. Why an HTTP 200 is the failure that matters, and
what a stderr-reporting CLI would cost, are the PR's and the follow-up
issue's job, not the manifest's.
This commit is contained in:
atlas 2026-08-14 16:02:10 +02:00 • committed by mara
commit 34fed47400
2 changed files with 7 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

9
hive-metric/Cargo.toml
View file

@ -19,13 +19,8 @@ opentelemetry_sdk = { version = "0.32", features = ["metrics"] }
# so the async client panics there with "no reactor running". The blocking
# client sends on that thread directly — and for a fire-and-forget CLI that
# records one point then `shutdown()`s, a synchronous send is exactly right.
#
# Deliberately WITHOUT the `internal-logs` feature that `hive-c0re` names, even
# though the defect is identical: this binary installs no `tracing` subscriber,
# so the SDK's diagnostics would be emitted into a void. Enabling it here would
# read as "hive-metric reports its export failures" while changing nothing at
# all. Giving this CLI somewhere to report is a behaviour change with its own
# decision (does a metrics push print to stderr?) — tracked separately.
# No `internal-logs` here, unlike hive-c0re: this binary installs no tracing
# subscriber, so the SDK's diagnostics would have nowhere to go.
opentelemetry-otlp = { version = "0.32", default-features = false, features = [
"metrics",
"http-json",