Closed KolbyML closed 5 months ago
Here is a node on our cluster
Notice that the uTP request was successful!!!!
now lets check the logs
2023-10-10T00:05:33.532006Z WARN portalnet::overlay_service: Accepted content outside radius or already stored content.key=0x01a30169098a44f02845764727f9873b64ddad7ba9813dbf41c05741fec499d31d
2023-10-10T00:05:53.337305Z WARN portalnet::overlay_service: Accepted content outside radius or already stored content.key=0x0050400fcad1e0da329bd402b5fb0cb86c9ecf69c7e4734618d4b01f1ba2776867
^ we basically get this. I didn't have a chance to record this for posting here, but it was this.
nvm ^ this is not confirmed yet
checking if the content is stored locally
Python 3.8.10 (default, May 26 2023, 14:05:08)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from web3 import Web3
>>> w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545', request_kwargs={'timeout': 61}))
>>> print(w3.provider.make_request("portal_historyLocalContent", ["0x01823def5821988f866db5d2e9400ec9c9df613f299677aa577a0ff9c0ee631c35"]))
{'jsonrpc': '2.0', 'result': '0x', 'id': 0}
>>>
So it appears like the issue would bewith accepting content outside the radius?
Tbh, it's just a bit difficult for me to understand the problem you're trying to debug here?
I am confused now cause if the finland node is running on modified trin code this should be working I would think
Personally, I don't think it's a good use of our time to be debugging against peers who are not running core trin code, otherwise it could just lead to wasted time / rabbitholes debugging the wrong source code.
That's quite a big chunk of logs :sweat_smile: while I'm sure there's some useful stuff in there, there's nothing more intimidating than staring at a massive wall of logs to look through in github. Next time, I'd replace any logs that are not relevant to the issue with a ...
or something
I was gossiping content using the bridge. For some reason it was only accepted by 2 nodes in Finland.
How do you know this? What mode are you using the bridge?
Tbh, it's just a bit difficult for me to understand the problem you're trying to debug here?
Personally, I don't think it's a good use of our time to be debugging against peers who are not running core trin code, otherwise it could just lead to wasted time / rabbitholes debugging the wrong source code.
They are running core trin code
That's quite a big chunk of logs 😅 while I'm sure there's some useful stuff in there, there's nothing more intimidating than staring at a massive wall of logs to look through in github. Next time, I'd replace any logs that are not relevant to the issue with a
...
or something
All the logs are relevant
I was gossiping content using the bridge. For some reason it was only accepted by 2 nodes in Finland.
How do you know this? What mode are you using the bridge?
That was on one of my runs of the bridge. The bridge was using single mode with a timer on the end because this is a issue with the bridge not waiting for the blocks to gossip before closing Trin. I know it was 2 nodes from Finland because I logged the Enr's which accepted content. My local gossip instead of returning how many nodes you offer the content to which doesn't say anything it tells you how many nodes accepted the offer and the enr's of those respective nodes so then you can check the geographical location from the IP.
The first message is the finland node, but the second message is us replicating the same issue of us successful gossiping a block to a node on our cluster then it not being there with 0 errors something happened.
The logs tell you the transfer was a success which is very useful to know.
The second message I posted https://github.com/ethereum/trin/issues/972#issuecomment-1754110393 accepts the offer gets the content successful then displays no error that anything wrong happened.
Without trace logs on the cluster node I would have 0 idea what happened or if it got the data successfully or why.
I later found out the nodes from Finland were being ran by Qi from EthStorage which we had a long conversion in #trin . This issue is mostly for me to organize logs and stuff that will be useful for future reference, almost like a debug journal.
If the Finland nodes are running trin source code then what does this mean? I am confused now cause if the finland node is running on modified trin code this should be working I would think
.
All the logs are relevant / The logs tell you the transfer was a success which is very useful to know.
Sure, but what I'm talking about is I don't need to see every ack for every data packet that was sent hahaha
This issue is mostly for me to organize logs and stuff that will be useful for future reference, almost like a debug journal.
Ok, this helps a lot. I'm not sure if it's the best use of the issue board, tbh. I'd recommend using a local markdown organizer. I personally like to use obsidian. Or if you want to create a label ... something like no-feedback
.. that way others know not to read through the issue
If the Finland nodes are running trin source code then what does this mean?
I am confused now cause if the finland node is running on modified trin code this should be working I would think
.
At the time I was confused cause I wrote that before I came to the realization it was probably Qi running the nodes. I was confused because the behavior of the nodes was non-deterministic. A better picture of what happened can be seen in the discord chat but basically.
I ping Qi's node 80 it gives me a radius of 1%. Qi pings his node 80 locally it gives him a radius of 100%.
Which is very strange? He is also using unique Private keys for each node so I don't know how the messages could be misrouted 1 vs 100% is massive and perplexed me.
According to the math something was off
This issue is mostly for me to organize logs and stuff that will be useful for future reference, almost like a debug journal.
Ok, this helps a lot. I'm not sure if it's the best use of the issue board, tbh. I'd recommend using a local markdown organizer. I personally like to use obsidian. Or if you want to create a label ... something like
no-feedback
.. that way others know not to read through the issue
Hmm I could look into obsidian. I wanted to post it here to leave like a paper trail of what I was looking into for the possibility another person wanted to see it. Adding no-feedback
is very fair I will add that.
This issue is stale because it has been open for 180 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
I was gossiping content using the bridge. For some reason it was only accepted by 2 nodes in Finland. When I did RFC it would fail. When I FC directly to one of the nodes I would just get the error
{'jsonrpc': '2.0', 'error': {'code': -32099, 'message': 'FindContent request timeout: Timeout'}, 'id': 0}
The nodes radius I pinged was 1.372494744% or
0x381cb22dde95c4282adeb5abe2afd87a50400ca92e78c78f4acf348223095c6
0x3f1c1dce64a7e5d40a1e0c561500f1dc5cf08918fcb531af69afdd375cc6b976 > 0x381cb22dde95c4282adeb5abe2afd87a50400ca92e78c78f4acf348223095c6
But the distance to the content is
0x3f1c1dce64a7e5d40a1e0c561500f1dc5cf08918fcb531af69afdd375cc6b976
since the content id is0x978e003e087fb7f21833fd43136d126ba97e0fffb90b6c04ebea9ba55c877fee
and the node id is0xa8921df06cd85226122df115066de3b7f58e86e745be5dab824546920041c698
Now I am just confused cause shouldn't it only accept it if
I just sent it an offer request and it is still saying it will accept it
{'jsonrpc': '2.0', 'result': {'contentKeys': '0x03'}, 'id': 0}
I am confused now cause if the finland node is running on modified trin code this should be working I would think