-
Notifications
You must be signed in to change notification settings - Fork 11
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
req-resp: Connection closed with peer that does not exist #290
Comments
Code AssumptionsThe issue manifests in request-response protocol when receiving litep2p/src/protocol/request_response/mod.rs Lines 895 to 897 in eed0f75
The events originate from the transport service component: litep2p/src/protocol/transport_service.rs Lines 562 to 578 in eed0f75
It is clear that the transport service contains the appropriate information of connections, otherwise it would have paniced before the request-response protocol here: litep2p/src/protocol/transport_service.rs Lines 386 to 396 in eed0f75
Root CauseTransportService reports only primary connections via T0: TransportService accepts connection A for peer X as primary, event reported Request Response protocol received events:
Secondary not reported as ConnectionEstablished: litep2p/src/protocol/transport_service.rs Lines 361 to 365 in eed0f75
Secondary promoted to Primary without events: litep2p/src/protocol/transport_service.rs Lines 408 to 417 in eed0f75
|
Since we report only peerIDs, and not (peerIDs++conectionIDs) it may also be possible that req-resp skipped / did not received |
The issue looks like a state mismatch in request-response handler:
Grafana link: https://grafana.teleport.parity.io/goto/YI3Ois7Ng?orgId=1 On connection established, we try to open a substream to the remote peer. However, the substream open request can fail with litep2p/src/protocol/request_response/mod.rs Lines 267 to 284 in eed0f75
This is simply an edge case where we discovered the connection is closed by relying on substream activity instead of events from TransportManager |
…291) When a new connection is reported to the request-response protocol, the protocol tracks the state of the connection if and only if it could open a substream with the remote peer. We do not track the state of the connection in cases where the substream cannot be opened because the connection is closed. A further `ConnectionClosed` event triggered a debug_assert assumption for this case. The assumption is wrong since opening substreams can fail which informs us that the connection is closed. Connection details not tracked: https://github.com/paritytech/litep2p/blob/eed0f755d591eb49e1b715a78aceb5a653ddf529/src/protocol/request_response/mod.rs#L267-L284 Which later leads to panics: https://github.com/paritytech/litep2p/blob/d6fae559fbe2aaf8cb3fff021fb5608ca7b43766/src/protocol/request_response/mod.rs#L295-L301 Related to: #290 --------- Signed-off-by: Alexandru Vasile <[email protected]>
Closed by: #291 |
Grafana link: https://grafana.teleport.parity.io/goto/JgobqPnHg?orgId=1
The text was updated successfully, but these errors were encountered: