-
Notifications
You must be signed in to change notification settings - Fork 995
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(core): add logs for OrTransport
when trying addresses
#4133
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Two suggestions :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for addressing the comments! Did you test this with an application or an example?
I am curious what these log lines end up looking like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat. This will help a lot in the future. Thank you.
Also curious what the output looks like. Mind posting it here?
Co-authored-by: Max Inden <[email protected]>
Co-authored-by: Max Inden <[email protected]>
@mxinden @thomaseizinger I've tested with the simplest template in [2023-06-30T19:12:43Z TRACE libp2p_core::transport::choice] Attempting to dial /memory/3374154575862174647 using libp2p_relay::priv_client::transport::Transport
[2023-06-30T19:12:43Z DEBUG libp2p_core::transport::choice] Failed to dial /memory/3374154575862174647 using libp2p_relay::priv_client::transport::Transport
[2023-06-30T19:12:43Z TRACE libp2p_core::transport::choice] Attempting to dial /memory/3374154575862174647 using libp2p_core::transport::memory::MemoryTransport |
Perhaps we should reduce this to just logging the failures to be less noisy? My guess is that connections succeeding is almost never an issue. It is the rejections that are hard to debug. Thoughts guys? |
@thomaseizinger As you wish, for me it's not a major problem because the But if you prefer, no worries, I can just remove the two |
Given that the success case is on TRACE level this looks good to me. Though not a strong opinion. Will defer to @thomaseizinger. Thank you @tcoratger. |
Approvals have been dismissed because the PR was updated after the send-it
label was applied.
- Fixes typo in `<OrTransport as Transport>::listen_on` using the word "dial" instead of "listen_on". - Adds logging to `<OrTransport as Transport>::dial`. Follow-up to libp2p#4133
When you enable Kademlia in a large network that uses multiple type of transports, then this log creates a very noisy console and makes meaningful logs hard to see. We can also remove the log entirely if you prefer. Check: #4015 (comment), #4072, #4133 Pull-Request: #5396.
When you enable Kademlia in a large network that uses multiple type of transports, then this log creates a very noisy console and makes meaningful logs hard to see. We can also remove the log entirely if you prefer. Check: libp2p#4015 (comment), libp2p#4072, libp2p#4133 Pull-Request: libp2p#5396.
Description
Currently, when trying addresses in
listen_on
viaOrTransport
, there are no logs to facilitate debugging. This PR corrects that by providing adequate logs viastd::any::type_name
method.Resolves #4072.
Notes & open questions
Change checklist