System traffic no longer counts as application message metrics (CritterWatch GH-907) - #3759
Merged
Merged
Conversation
…erWatch GH-907) An idle Wolverine app with CritterWatch applied reported ~150 messages a minute of nothing but its own machinery: agent commands on the node control queues, acknowledgements, and CritterWatch's monitoring messages — the last of which fed back on itself, since the accumulator's exports are published to CritterWatch as messages that were themselves counted. Three gaps closed, all resolved ONCE at construction time (per endpoint, per executor) with no per-envelope branching, following the same shape as InlineSendingAgent's sendWithTracing/sendWithOutTracing split: - The meter counters in WolverineRuntime.Tracking were unconditional — every send incremented wolverine-messages-sent no matter what the traffic was. Sending agents, local queues, and listening pipelines now resolve their tracker through MessageTrackingFor(endpoint): a System-role endpoint or one with TelemetryEnabled = false gets the new metrics-silent SystemTrafficMessageTracker, which keeps the debug logging, tracked-session bookkeeping, and wire taps but records nothing. - The executor factory excluded only IAgentCommand, and only in the CritterWatch publishing modes. It now excludes the full system-message surface (IInternalMessage, IAgentCommand, INotToBeRouted — which covers ICritterWatchMessage and acknowledgements — and opted-out assemblies) in EVERY metrics mode, and consults the endpoint's role as well. - An endpoint promoted to node control duty (UseTcpForControlEndpoint) never received the System role, unlike the database and shared-memory control endpoints that are born with it. The NodeControlEndpoint setter stamps it now. The old IsSystemEndpoint string match stays as defense in depth for the accumulator paths, but the classification the system actually relies on is EndpointRole, per the GH-907 acceptance criteria. Wolverine.CritterWatch's own endpoints get marked System-role in a matching CritterWatch-repo change (InternalsVisibleTo already covers it). Full CoreTests (2176) and MetricsTests (25, including the pump tests that prove application traffic is still counted in CritterWatch/Hybrid modes) pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013eR4GL278688VhyhrGcttJ
…em-traffic-metrics
This was referenced Aug 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the Wolverine half of CritterWatch #907: an idle Wolverine app with CritterWatch applied reported ~150 messages/minute of nothing but its own machinery — agent commands on the control queues, acks, and CritterWatch's monitoring messages, the last of which fed back on itself (accumulator exports are published to CritterWatch as messages that were themselves counted).
The three gaps
wolverine-messages-sentincremented for every send regardless of what the traffic was (theTelemetryEnabledflag gated spans, never metrics). Sending agents, local queues, and listening pipelines now resolve their tracker viaMessageTrackingFor(endpoint)— a System-role endpoint or one withTelemetryEnabled = falsegets a new metrics-silentSystemTrafficMessageTrackerthat keeps debug logging, tracked-session bookkeeping, and wire taps, but records nothing.IAgentCommand, and only in the CritterWatch modes. It now excludes the full system-message surface via the existingIsSystemMessageType()predicate (IInternalMessage,IAgentCommand,INotToBeRouted— which coversICritterWatchMessageand acknowledgements — and opted-out assemblies), in every metrics mode, and consults the endpoint role too.UseTcpForControlEndpointnever stamped the System role on the endpoint it promoted, unlike the database/shared-memory control endpoints that are born with it. TheNodeControlEndpointsetter stamps it now.Design constraints honored (from the issue)
sendWithTracing/sendWithOutTracingpattern.EndpointRole, not string matching, is the classification the system relies on; the oldIsSystemEndpointstring match stays only as defense in depth on the accumulator paths.Behavior change to be aware of
Endpoint.TelemetryEnabled = falsenow silences metrics as well as traces for that endpoint, and system message types no longer appear in any message-level instrument in any mode. The metrics docs gained a callout.Testing
system_traffic_metrics_silencingsuite in CoreTests (9 tests): tracker selection per role/flag/message type, control-endpoint promotion, and MeterListener-verified silence vs. counting.Companion change
Wolverine.CritterWatchwill mark its own outbound/inbound endpoints System-role in a CritterWatch-repo PR (InternalsVisibleToalready covers it); end-to-end idle-app verification lands there per the issue.🤖 Generated with Claude Code
https://claude.ai/code/session_013eR4GL278688VhyhrGcttJ