mina advanced node-status appears to be broken

[cjjdespres]

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/MinaProtocol/mina/issues
• This issue is not a question, feature request, RFC, or anything other than a bug report. Please post those things in GitHub Discussions: https://github.com/MinaProtocol/mina/discussions

Description

The mina advanced node-status doc string says:

Get node statuses for a set of peers

If you run mina advanced node-status --daemon-peers (to get the status of every known peer), you ought to see some output, especially if the daemon is synced to the network and has a lot of peers. What you will see is empty output, which is wrong.

I ran mina advanced node-status --daemon-peers --show-errors (so errors in getting the status of the peers would also be output) and got this output repeated ~22 times (which was the number of peers I was connected to at the time)

{"error":{"exn_name":"Base__Exn.Sexp","exn":["Yojson.Json_error(\"Line 1, bytes 65523-65524:\\nUnexpected end of input\")"]}}

Claude speculates that this is due to this code in libp2p:

mina/src/app/libp2p_helper/src/libp2p_helper/peer_msg.go

Lines 105 to 107 in f5bf72d

	n, err := s.Read(data)
	// TODO will the whole status be read or we can "accidentally" read only
	// part of it?

The TODO seems relevant. If this is indeed the issue, then it's because that Read call is only reading a single chunk of the status reply.

N.B. I think a test of this could be added in the CI somewhere. I think this might show up in a 2-node test network spun up in a test. It would probably be observable in a network connectivity test too (to actual mainnet or devnet). Once a test is added, it'll be easier to see if changing the Read call will fix this command, or if the failure is somewhere else. Also, if the same code serves a graphql endpoint then it might be easier to use that in a test. Unsure.

Steps to Reproduce

1. Sync a daemon to a network (it probably doesn't have to be synced, but it doesn't hurt)
2. Confirm that the daemon is connected to some non-zero number of peers (with mina client status, or otherwise - the graphql interface is probably more convenient in a test)
3. Run mina advanced node-status --daemon-peers --show-errors
4. Observe all the Unexpected end of input failure lines

Expected Result

No failures due to unexpected end of input

Actual Result

Failures due to unexpected end of input

Daemon version

42ec1eb on compatible, but I'd imagine this is reasonably long-standing

How frequently do you see this issue?

Always

What is the impact of this issue on your ability to run a node?

Low

Status

.

Additional information

No response

[cjjdespres]

It's possible that whatever gets returned from the peer status got a lot bigger, and doesn't fit in a single input received chunk any more. So this might have accidentally worked in the past, but stopped working once the status got bigger. That's just speculation, though.

For reference, the libp2p helper allocates a buffer of size := 1048576 (1MB), but appears to be reading just a single chunk of input from the network.