Closed henridf closed 1 year ago
Adding a few comments/questions as I poke around:
MetaDataRPCv1
where the protocol is marked as /eth2/beacon_chain/req/metadata/1/ssz
. But based on the spec, shouldn't the encoding be ssz_snappy
? (I did try with that but no change in results)Hey @henridf ! Thank you very much for being active in the repo!
About the errors that were listed in the Issue:
You are right about the context deadline exceeded
error. By using the connection notifier
of the Libp2p.Host
, I'm trying to re-use the libp2p stream to request all the metadata for every connected peer (incoming or outcoming connection). For some reason, there are some not-so-rare cases where the host.Connect()
function in peering/peering.go
raises the connection notifier while the function itself reports a connection error context deadline exceed
(I didn't have much time to take a look at it). In this case, we are trying to use a Libp2p.Stream
linked to a no-longer live context.
About the protocol not supported
, initially, RPC requests with plain ssz serialization were supported along the snappy compressed ones by every client, that is why I didn't bother to change them (shame on me 😓).
Now, after the Altair fork, it seems they have added an extra field in the RPC response-chunk, which we are not supporting (yet) and that causes the failed to read chunk 0 result byte: closed stream"
one.
I won't have much time to dig into this over this week, although I might be able to fix this over the late-next one.
Also, just for you to know, I'm planning on reorganizing the crawler over the summer (especially the SQL database), so let me know or feel free to open an issue if there is something you think is missing.
Thanks for the quick response @cortze ! I'm going to take a stab at addressing these issues.
Also, just for you to know, I'm planning on reorganizing the crawler over the summer (especially the SQL database), so let me know or feel free to open an issue if there is something you think is missing.
Interesting and thanks for heads up. Is this a general refactor/cleanup type of reorg or do you have any feature/functional changes in mind?
It will be a general clean up refactor with a specific focus on the SQL database. I really think that the code can be refactored in a more modular way and it starts by cleaning up the DB.
After that, I'm thinking of adding more GossipSub-oriented metrics or submodules, but the overall functionality of the tool should remain intact. We are, in fact, using it as the main data source for our public dashboard
closing this, as it is solved in #52
I'm running
armiarma eth2
and not getting any of the beacon metadata fields. The logs indicate mostly "deadline exceeded" errors, and some others. Before I dig further into this, any obvious gotchas that I may be missing?(note this is not the verbatim log, it is grepped for "metadata")