Resource usage meter is never fed data in production

[sanity]

Problem

TopologyManager::report_resource_usage() is marked #[allow(dead_code)] // fixme: use this and is only called from test code within the topology module. No production code feeds resource usage data into the Meter.

This means calculate_usage_proportion() always returns ~0% usage, so adjust_topology() always takes the "usage below 50% → add connections" branch. The resource-usage-based decision logic (add when <50%, hold at 50-90%, remove when >90%) effectively never gates connection changes based on actual load.

Affected code

• crates/core/src/topology/mod.rs — report_resource_usage() (line ~237), report_split_resource_usage() (line ~220)
• crates/core/src/topology/meter.rs — Meter struct and all its attribution tracking
• crates/core/src/topology/mod.rs — calculate_usage_proportion(), extrapolated_usage()

Impact

• The topology manager cannot make load-aware decisions about adding/removing connections
• The "remove worst-value peer when overloaded" path (select_connections_to_remove) is unreachable in production
• Tests pass because they call report_resource_usage directly, masking the production gap

What needs to happen

Wire up actual resource usage reporting from the node's event loop or transport layer into TopologyManager::report_resource_usage(). The meter infrastructure exists and is tested — it just needs a caller that feeds it real bandwidth/CPU data from production traffic.

[AI-assisted - Claude]

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-bug (98% confidence)
• P-high (90% confidence)
• E-medium (80% confidence)
• A-networking (95% confidence)

Reasoning: The report describes production code not invoking the resource-usage reporter, causing topology decision logic to always see ~0% usage. This is a correctness bug in topology behavior (T-bug). It affects the network's ability to make load-aware connection changes across nodes, so it should be treated as high priority (P-high). Fixing it requires wiring the event loop/transport to call the existing Meter APIs—nontrivial but localized work (E-medium). The issue clearly pertains to connection/topology logic within the networking layer (A-networking).

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.

[sanity]

Issue Priority Assessment

Generated: 2026-03-12T22:28:10.720697325+00:00
Issue hash: 7bae0af4

Value Assessment

Relevance check: The core of the issue still exists in the current tree—TopologyManager::report_resource_usage and report_split_resource_usage remain annotated with #[allow(dead_code)] // fixme: use this and are only referenced inside the test harness in crates/core/src/topology.rs around lines 230‑268 and again near lines 1070‑1292, where helper functions push synthetic bandwidth data to the Meter. There are no other call sites anywhere in the repository, so production builds never instantiate report_resource_usage and source_creation_times never fill with real peers. Nothing in the surrounding modules or event loop has gained a new hook since this issue was filed, so the same “never fed data in production” situation still obtains today.

User impact: Because no real resource data ever reaches the meter, calculate_usage_proportion (lines 520‑533) always iterates over an empty source_creation_times map and returns zero usage for every resource type. When adjust_topology (lines 336‑489) runs, it therefore always interprets the topology as underutilized and takes the “add connections” branch, so the resource-pressure code paths (including select_connections_to_remove) never run except for hit‑the‑roof max-connection enforcement; overloaded nodes never trigger the “remove worst-value peer” logic. This undermines the production value of the topology manager’s load-aware behavior, causes nodes to over-connect rather than shed load, and leaves the expensive removal-selection code permanently dormant despite the tests that only work because they push fake samples through the unused API.

Strategic alignment: The topology manager’s resource-meter infrastructure was clearly built to let the node add or remove peers based on measured bandwidth, with the attendant goals of keeping the network stable under load and rewarding valuable peers. Without wiring the production event loop or transport layer into report_resource_usage, that strategic capability can’t be delivered—future work on improving load balancing, eviction heuristics, or connection acquisition strategies all depend on the same measurement pipeline. Feeding real bandwidth/CPU samples into the existing Meter is therefore a prerequisite for any further enhancements in this area, and it should be part of any roadmap item touching topology resilience.

Blocking factor and urgency: While this gap doesn’t block other unrelated code changes, it does mean several high‑impact behaviors (load-based removals, swap suppression under load, and topology value comparisons) are never exercised in production, which in turn makes future debugging of overload scenarios harder. There’s no immediate hard deadline, but because the issue causes the node to keep adding peers even when actually saturated, it makes the system more vulnerable to resource exhaustion and should be addressed sooner rather than later to avoid unintended growth in live deployments.

Cost Assessment

The issue is still actionable because report_resource_usage is marked #[allow(dead_code)] and never invoked outside the unit tests (crates/core/src/topology.rs:250, crates/core/src/topology.rs:1094), so the Meter in TopologyManager never sees production traffic. As a result adjust_topology on the regular connection-maintenance tick (crates/core/src/ring.rs:2144) always reads ~0% usage, which is why the 50–90% resource gate is never hit. The only production candidate that already records per-peer bandwidth is TRANSPORT_METRICS.per_peer_snapshot() (crates/core/src/transport/metrics.rs:59-110), so the work here is about plumbing a bridge from that snapshot into TopologyManager before the topology decision fires.

Scope-wise, the change lives entirely inside the ring/connection-maintenance path: collect the latest per-peer (sent, recv) counts via TransportMetrics::per_peer_snapshot() and keep a small HashMap<SocketAddr, (u64, u64)> across ticks to compute the delta per address. For each delta we resolve the address into a PeerKeyLocation through connection_manager.get_peer_by_addr (crates/core/src/ring/connection_manager.rs:792-834), convert to AttributionSource::Peer, and feed both inbound and outbound bytes into TopologyManager::report_resource_usage (crates/core/src/topology.rs:250) before calling adjust_topology. That also means reorganising the existing topology_manager.write() block around adjust_topology so we can batch the report_resource_usage calls and keep the write lock held only once, and declaring the helper that produces usage samples close to the connection_maintenance loop.

There are no external dependencies here—just existing globals—but there are a few risks to manage. The TransportMetrics per-peer map is capped at MAX_TRACKED_PEERS (256) (crates/core/src/transport/metrics.rs:91), so under high fan-out we may miss some peers and still see low aggregate usage; the mitigation is to accept the bound and perhaps prioritize active peers instead of failing loudly. A second risk is that many addresses (especially during handshake) might not yet resolve to a PeerKeyLocation, so get_peer_by_addr can return None; we should simply skip those entries to avoid logging bogus data. Finally, we must be careful that the new per-tick scan and the report_resource_usage calls don’t hold the topology lock for too long—inserting them before adjust_topology inside the same guard strikes a good balance.

Testing will need to grow: the current explicit uses of report_resource_usage in TopologyManager tests (crates/core/src/topology.rs:1094 and the subsequent add/remove/no-change cases) prove the logic, so we should add at least one unit test of the new helper to drive a fake TransportMetrics snapshot and ensure the delta feeding actually invokes the meter (e.g., by injecting a fake TransportMetrics state and checking adjust_topology now takes the remove branch under high usage). It might also be worth having a small integration-style test that runs the connection-maintenance loop with a mocked TransportMetrics so we can exercise the adjustment path without manually calling report_resource_usage, guaranteeing the production plumbing forces the same behavior as the current test-only instrumentation.

---

Generated by issue-prioritizer