[Hubble] http info api returns error while getting snapshot and contracts

[jgresham]

What is the bug? I use this API to show the hubble version and whether it is syncing in NiceNode. It would be good if users could see the hubble version, syncing status, and other info right after it is started.

How can it be reproduced? (optional)

1. Start hubble
2. call https://www.thehubble.xyz/docs/httpapi/info.html#info curl http://localhost:2281/v1/info
3. Receive response: curl: (56) Recv failure: Connection reset by peer

Additional context (optional) Additionally, even when the base /info api starts working, adding dbstats=1 as in the info docs, returns no matches found (ex. curl http://localhost:2281/v1/info?dbstats=1 -> zsh: no matches found: http://localhost:2281/v1/info?dbstats=1)

[sds]

HTTP API support was released relatively recently—it might be worth double checking that you're running Hubble version 1.6.0 or newer, and that you don't have the --http-server-disabled flag specified.

You can try this out below:

⨠ curl "http://nemes.farcaster.xyz:2281/v1/info"              
{"version":"1.6.0","isSyncing":false,"nickname":"nemes","rootHash":"f425e51f5096c73a4b0c6da06c9f8e950f1cf7c1","peerId":"12D3KooWMQrf6unpGJfLBmTGy3eKTo4cGcXktWRbgMnfbZLXqBbn","hubOperatorFid":9152}

⨠ curl "http://nemes.farcaster.xyz:2281/v1/info?dbstats=1"
{"version":"1.6.0","isSyncing":false,"nickname":"nemes","rootHash":"a8756d1f0460abc8db8cb3ed7bab51fa8258cc93","dbStats":{"numMessages":4515680,"numFidEvents":20840,"numFnameEvents":20706},"peerId":"12D3KooWMQrf6unpGJfLBmTGy3eKTo4cGcXktWRbgMnfbZLXqBbn","hubOperatorFid":9152}

Notice that we're wrapping the URL with quotes. The error message in your issue suggests that your shell (zsh) is interpreting the URL incorrectly, which is easily solved by wrapping the URL with quotes. Hope this helps.

[jgresham]

@sds the problem is that the API fails while Hubble is getting snapshot and contracts, and syncing storage cache, right after starting

[sds]

Got it. I'm not sure there's much we can do in this situation, but I'll leave it to the protocol team to triage further. Thanks!

[jgresham]

This is fixed in(or before) v1.6.4!