Measured
On all three standing fleet boxes (us-east-1, eu-west-1, ap-southeast-1), dig-node 0.135.0, every one healthy and on the network:
dig-node network-info --json → empty outputdig-node peers --json → works, returns the full peer set
Found incidentally while verifying the #923 bootstrap anchor. Not investigated further — it was outside that task's path.
Why it clears the bar
A shipped CLI verb returning nothing on a healthy node is user-visible: a person cannot distinguish "this node has no network info" from "this command is broken". Empty is not an error and not an answer.
Note the node genuinely had network state at the time — peers --json on the same box in the same session returned a populated peer set including the anchor at [2600:1f18:4941:2a00:4105:40f3:80db:9db5]:9445, via: direct. So the data exists; the verb is not surfacing it.
Worth checking while in there
- Does it exit 0? An empty body with a success code is the worst combination — a script cannot detect it.
- Is this the
--json path only, or does the human-readable form fail the same way? #426's CLI-parity drift test exists for exactly this class.
- Is the verb reaching the control plane at all, or answering locally from state it does not have?
Reproduce
Any healthy node. On the fleet, via .claude/scripts/fleet/_ssm-run.sh — and note that helper's trap: the Windows AWS CLI silently returns empty SSM output when the payload contains non-ASCII unless PYTHONIOENCODING=utf-8 is set. That trap was accounted for here — peers --json returned output through the same helper in the same invocation, so the emptiness is the verb's, not the transport's.
Measured
On all three standing fleet boxes (
us-east-1,eu-west-1,ap-southeast-1), dig-node 0.135.0, every one healthy and on the network:dig-node network-info --json→ empty outputdig-node peers --json→ works, returns the full peer setFound incidentally while verifying the #923 bootstrap anchor. Not investigated further — it was outside that task's path.
Why it clears the bar
A shipped CLI verb returning nothing on a healthy node is user-visible: a person cannot distinguish "this node has no network info" from "this command is broken". Empty is not an error and not an answer.
Note the node genuinely had network state at the time —
peers --jsonon the same box in the same session returned a populated peer set including the anchor at[2600:1f18:4941:2a00:4105:40f3:80db:9db5]:9445, via: direct. So the data exists; the verb is not surfacing it.Worth checking while in there
--jsonpath only, or does the human-readable form fail the same way? #426's CLI-parity drift test exists for exactly this class.Reproduce
Any healthy node. On the fleet, via
.claude/scripts/fleet/_ssm-run.sh— and note that helper's trap: the Windows AWS CLI silently returns empty SSM output when the payload contains non-ASCII unlessPYTHONIOENCODING=utf-8is set. That trap was accounted for here —peers --jsonreturned output through the same helper in the same invocation, so the emptiness is the verb's, not the transport's.