paritytech
Is it possible to remove this warning message
- It would help if you submit info about the system you are running, e.g.: operating system, kernel version, amount of available memory and swap, etc.
Linux ~20.04.1-Ubuntu SMP Wed Jun 22 19:07:51 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
- Logs could be very helpful. If possible, submit the whole log. Please format it as
code blocks.
Compiling polkadot-overseer v0.9.26 (https://github.com/paritytech/polkadot?branch=release-v0.9.26#d8785970)
⚡ Found 1 strongly connected component which includes at least one cycle
cycle(001) ∈ α: NetworkBridge ~~{"BitfieldDistributionMessage"}~~> BitfieldDistribution ~~{"NetworkBridgeMessage"}~~> *
⚡ Found 1 strongly connected component which includes at least one cycle
cycle(001) ∈ α: NetworkBridge ~~{"CollationGenerationMessage"}~~> CollationGeneration ~~{"CollatorProtocolMessage"}~~> CollatorProtocol ~~{"NetworkBridgeMessage"}~~> *
Compiling polkadot-node-subsystem v0.9.26 (https://github.com/paritytech/polkadot?branch=release-v0.9.26#d8785970)
Compiling polkadot-node-subsystem-util v0.9.26 (https://github.com/paritytech/polkadot?branch=release-v0.9.26#d8785970)
- Describe the role your node plays, e.g. validator, full node or light client.
- Any command-line options were passed?
cargo build --release
@yrong if you are referring to the cycle detection warnings, this is actually a feature which is really useful. Is it breaking anything for you ?
@yrong if you are referring to the cycle detection warnings, this is actually a feature which is really useful. Is it breaking anything for you ?
nothing block. just feel not perfect to see it here and wondering if we can eliminate such cycle reference, maybe some refact I'm not not sure.
I'm not really sure if we can remove them all, but that needs to be carefully looked at to have a good answer.
I also don't get why we need this output, apparently it is ignored anyway, because no one fixes it. IMO, we should hide them behind a feature flag. You could then for example let them being outputted by the CI or just on local runs when you need to know.
We can replace println!s with eprintln!s, they won't be visible by default in that case.
