-
Notifications
You must be signed in to change notification settings - Fork 754
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
Spamming Westend causes grandpa-voter
to fail
#6507
Comments
We need more logs. @lovelaced please enable After that is done we need the script again @tugytur |
|
The gossip engine exists when either the notification event stream closes or the sync event stream closes: polkadot-sdk/substrate/client/network-gossip/src/bridge.rs Lines 247 to 251 in 04e2bd3
polkadot-sdk/substrate/client/network-gossip/src/bridge.rs Lines 262 to 266 in 04e2bd3
Have detected a poll mismatch implementation, although I don't expect that to be the root cause of this issue: We'll probably need to collect more logs. @tugytur Would it be possible to make the script public? Would like to run this in versi-net to check litep2p as well 🙏 |
…6553) The `GossipEngine::poll_next` implementation polls both the `notification_service` and the `sync_event_stream`. If both polls produce valid data to be processed (`Poll::Ready(Some(..))`), then the sync event is ignored when we receive `NotificationEvent::NotificationStreamOpened` and the role cannot be deduced. This PR ensures both events are processed gracefully. While at it, I have added a warning to the sync engine related to `notification_service` producing `Poll::Ready(None)`. This effectively ensures that `SyncEvents` propagate to the network potentially fixing any state mismatch. For more context: #6507 cc @paritytech/sdk-node --------- Signed-off-by: Alexandru Vasile <[email protected]>
…aritytech#6553) The `GossipEngine::poll_next` implementation polls both the `notification_service` and the `sync_event_stream`. If both polls produce valid data to be processed (`Poll::Ready(Some(..))`), then the sync event is ignored when we receive `NotificationEvent::NotificationStreamOpened` and the role cannot be deduced. This PR ensures both events are processed gracefully. While at it, I have added a warning to the sync engine related to `notification_service` producing `Poll::Ready(None)`. This effectively ensures that `SyncEvents` propagate to the network potentially fixing any state mismatch. For more context: paritytech#6507 cc @paritytech/sdk-node --------- Signed-off-by: Alexandru Vasile <[email protected]>
@lexnv https://github.com/amforc/spammening but it was hard to get it running. We probably need some coordinated effort together with @tugytur to run it again on westend. |
In preparation for the spamming the Relaychains we were testing it on Westend.
After couple seconds of running the blocktime went >1 minute.
I don't have access to the validator logs/metrics, but thankfully @lovelaced checked.
This error showed up.
@lovelaced and I both suspect it could be caused by the low compute specs of the Westend valiators.
Would appreciate feedback if we should continue on Kusama or if Parity wants to first check some things on Westend.
For Kusama, we would first do a 1-3 minute run before doing the full 30 minutes couple days later.
If any more logs are required please reach out to @lovelaced and just let me know if you want me to run it on Westend again.
The text was updated successfully, but these errors were encountered: