Summary
Two maintainability improvements to prevent stale configuration and improve operational clarity.
Findings
1. Hardcoded node IDs in info.peers.sh will become stale
File: api/info.peers.sh, lines 10-16 and 27-29
The script has hardcoded node IDs for both Snow (testnet, 5 nodes) and Jade (mainnet, 1 node). When validators are rotated or decommissioned, this script silently returns empty or misleading results. The script also queries public Avalanche API endpoints directly rather than using the configurable env.sh, inconsistent with other API scripts.
Fix: Dynamically fetch current validators using platform.getCurrentValidators and extract node IDs, or accept node IDs as command-line arguments. Also source env.sh for consistency:
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
source "${SCRIPT_DIR}/env.sh"
2. Upgrade.json entries lack rationale documentation
Files:
avalanchego/configs/chains/2oo5UvYgFQikM7KBsMXFQE3RQv3xAFFc8JY2GEBNBF1tp4JaeZ/upgrade.json
avalanchego/configs/chains/2PDRxzc6jMbZSTLb3sufkVszgQc2jtDnYZGtDTAAfom1CTwPsE/upgrade.json
Both files contain precompile upgrades with timestamps that have already passed. The testnet file has a complex enable-then-disable-after-20-minutes pattern for contractDeployerAllowListConfig with no inline documentation. New operators have no way to understand the purpose or outcome of these entries.
Fix: Add a companion UPGRADE_HISTORY.md in the configs directory documenting each upgrade with rationale, execution date, and outcome. Update avalanchego/configs/README.md to describe the current state of precompile configurations.
Impact
- Peer monitoring could return stale/incorrect results after validator rotation
- New operators face confusion when deploying nodes with undocumented past upgrades
Generated by Health Monitor with Omni
Summary
Two maintainability improvements to prevent stale configuration and improve operational clarity.
Findings
1. Hardcoded node IDs in info.peers.sh will become stale
File:
api/info.peers.sh, lines 10-16 and 27-29The script has hardcoded node IDs for both Snow (testnet, 5 nodes) and Jade (mainnet, 1 node). When validators are rotated or decommissioned, this script silently returns empty or misleading results. The script also queries public Avalanche API endpoints directly rather than using the configurable
env.sh, inconsistent with other API scripts.Fix: Dynamically fetch current validators using
platform.getCurrentValidatorsand extract node IDs, or accept node IDs as command-line arguments. Also sourceenv.shfor consistency:2. Upgrade.json entries lack rationale documentation
Files:
avalanchego/configs/chains/2oo5UvYgFQikM7KBsMXFQE3RQv3xAFFc8JY2GEBNBF1tp4JaeZ/upgrade.jsonavalanchego/configs/chains/2PDRxzc6jMbZSTLb3sufkVszgQc2jtDnYZGtDTAAfom1CTwPsE/upgrade.jsonBoth files contain precompile upgrades with timestamps that have already passed. The testnet file has a complex enable-then-disable-after-20-minutes pattern for
contractDeployerAllowListConfigwith no inline documentation. New operators have no way to understand the purpose or outcome of these entries.Fix: Add a companion
UPGRADE_HISTORY.mdin the configs directory documenting each upgrade with rationale, execution date, and outcome. Updateavalanchego/configs/README.mdto describe the current state of precompile configurations.Impact
Generated by Health Monitor with Omni