Context
Code review of branch fix/valoper-signing-address-moniker (moniker resolution by signing address). Non-blocking follow-up.
Problem
Two code paths independently fan out one RPC call per valoper to fetch the same valoper profile render on every moniker refresh:
Each profile is therefore fetched twice per refresh cycle, doubling RPC round-trips for the same data.
Suggested fix
Unify into a single per-valoper fetch that parses both Signing Address and Server Type from one render, shared by both consumers.
Aside
The parse-format doc comment at health.go:~415 is now stale: the render uses - Operator Address: / - Signing Address:, not - Address: / - PubKey:.
Severity: medium (RPC efficiency / duplication).
Context
Code review of branch
fix/valoper-signing-address-moniker(moniker resolution by signing address). Non-blocking follow-up.Problem
Two code paths independently fan out one RPC call per valoper to fetch the same valoper profile render on every moniker refresh:
enrichValoperSigningAddresses—internal/gnovalidator/valoper.go— viavm/qevalvalopers.Render("<addr>"), parsesSigning Address.enrichValidatorInfoFromValopers—internal/gnovalidator/health.go:389— viavm/qrender, parsesServer Type.Each profile is therefore fetched twice per refresh cycle, doubling RPC round-trips for the same data.
Suggested fix
Unify into a single per-valoper fetch that parses both
Signing AddressandServer Typefrom one render, shared by both consumers.Aside
The parse-format doc comment at
health.go:~415is now stale: the render uses- Operator Address:/- Signing Address:, not- Address:/- PubKey:.Severity: medium (RPC efficiency / duplication).