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

Compare commits

base: vinzenz:3b9c004a0c0ddceced75ce89615051254af4a318
Branches Tags
vinzenz:main
...
compare: vinzenz:34fed47400182bf6b94a1a0340168f7380c4b403
Branches Tags
vinzenz:main
Author SHA1 Message Date
atlas
34fed47400 cut the comments back to what the code cannot say 
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.
 2026-08-14 23:16:59 +02:00
atlas
b28af3cd1f fix(c0re): stop compiling out the OTLP exporter's own diagnostics 
`default-features = false` on opentelemetry-otlp was written to trim
transports and dropped `internal-logs` with them, so every otel_warn! and
otel_debug! inside that crate compiled to nothing. The failure that
matters is the one which returns HTTP 200: the collector accepts the
request and rejects the data points, and HttpMetricsClient.PartialSuccess
is the only place the rejection count and the collector's reason are ever
surfaced.

The feature is per-crate, not per-workspace: the macros are exported by
the opentelemetry API crate but their cfg and CARGO_PKG_NAME resolve in
the calling crate, so the API crate and the SDK had internal logs on
while the exporter did not.

hive-metric keeps the identical declaration on purpose - it installs no
tracing subscriber, so the feature would be inert there and would only
mislead. Both files now record which side of that they are on, and the
stale "same features as hive-metric" comment is corrected.

Not sufficient on its own: a hard export failure is logged by the SDK at
debug on the compiled timer path, so it stays below the info filter.
That needs a level rather than a feature and is left to review.
 2026-08-14 23:16:59 +02:00
2 changed files with 8 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

9
hive-c0re/Cargo.toml
View file

@ -20,12 +20,15 @@ clap.workspace = true
clap_complete.workspace = true
clap-markdown = "0.1"
# OTEL SDK for the per-agent container-resource metrics exporter
# (stats/otel_metrics.rs). Same versions/features as hive-metric — the
# blocking OTLP client is deliberate: the metrics SDK's PeriodicReader runs
# on a background thread with no Tokio reactor, where the async client panics.
# (stats/otel_metrics.rs). Same versions as hive-metric — the blocking OTLP
# client is deliberate: the metrics SDK's PeriodicReader runs on a background
# thread with no Tokio reactor, where the async client panics.
opentelemetry = "0.32"
opentelemetry_sdk = { version = "0.32", features = ["metrics"] }
opentelemetry-otlp = { version = "0.32", default-features = false, features = [
# Not a transport: it is in `default`, so `default-features = false` drops the
# exporter's own diagnostics unless it is named here.
"internal-logs",
"metrics",
"http-json",
"reqwest-blocking-client",

2
hive-metric/Cargo.toml
View file

@ -19,6 +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.
# 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",