Skip to content
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

Validate connection manager/inbound governor transition order #3360

Merged
merged 6 commits into from
Nov 2, 2021

Conversation

bolt12
Copy link
Contributor

@bolt12 bolt12 commented Sep 20, 2021

No description provided.

@bolt12 bolt12 linked an issue Sep 22, 2021 that may be closed by this pull request
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch from b68bb6d to ef2d1fd Compare September 23, 2021 15:06
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch from 34c7cdc to de9a060 Compare October 1, 2021 11:30
@bolt12 bolt12 marked this pull request as ready for review October 1, 2021 11:37
@bolt12 bolt12 removed the request for review from njd42 October 1, 2021 11:38
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch 3 times, most recently from 47c06ba to 1add932 Compare October 4, 2021 10:24
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch 2 times, most recently from d8c306a to 15dd65b Compare October 6, 2021 08:19
@bolt12 bolt12 requested a review from coot October 6, 2021 08:19
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch 7 times, most recently from 5be3bbc to 4d0cca7 Compare October 8, 2021 12:02
@bolt12 bolt12 mentioned this pull request Oct 8, 2021
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch 4 times, most recently from 48b2528 to 03d9534 Compare October 12, 2021 13:05
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch from 634ead5 to fb4eb98 Compare October 21, 2021 11:54
@bolt12 bolt12 requested a review from coot October 21, 2021 14:12
@bolt12 bolt12 linked an issue Oct 22, 2021 that may be closed by this pull request
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch 2 times, most recently from 41d299f to 21b9799 Compare October 25, 2021 10:27
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch from 21b9799 to 29dcdfe Compare October 26, 2021 07:39
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch 3 times, most recently from 6ecf01c to e6c69cc Compare October 29, 2021 12:18
@bolt12 bolt12 requested a review from coot October 29, 2021 12:19
Copy link
Contributor

@coot coot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM; I left a minor comment (bang in modifyTMVarSTM), but this can be left for later as well (in that case create a github issue for it).

- In unregisterInboundConnectionImpl: OutboundDupState Ticking -> OutboundDupState Expired
- In withConnectionManager cleanup, where we put the state in TerminatedState is missing a trace. However, since this can be async the connState can come out of order and/or not making much sense.
- In requestOutboundConnectionImpl bracketOnError: TerminatedState -> Unknown
- In includeInboundConnectionImpl: on readPromise Left handleError case, where we put the state in either TerminatingState or TerminatedState
- In unregisterInboundConnectionImpl: Only trace TerminatingState -> TerminatedState, after having written to the connVar
- In a possible race between withConnectionManager finally block and forkConnectionHandler cleanup function, where the latter can run first and break an assumption made by withConnectionManager that it is the first to run so a connection shouldn't be in TerminatingState (which is not the case, since there is a race condition). So an out of order and possibly not making much sense transition is logged.
- When accept call returns first than connect and the connVar gets overwritten. In requestOutboundConnectionImpl cleanup function we wrongly trace * -> TerminatedState transition of a removed connVar, we shouldn't care about that connVar anymore.
- In promotedToWarmRemoteImpl, in OutboundIdleState case we are not updating the state correctly.
In promotedToWarmRemoteImpl (and family), it is possible that the STM action successfully commits, writing a new state to the connVar, but right after an AsyncCancelled is received making us omit the respective transition tracing.
Fixed issue in inboundGovernor function where in case of Async
exceptions we wouldn't log the final transitions for the connections.
- This way an assertion is not a pure exception evaluated when printing
an `io-sim` test case, but a simulation error. Note that this will hide
such exceptions from simulation. To test that such assertion do not
happen we can analyse trace.

- Check that `TrUnexpectedlyMissingConnectionState` is not logged.
This is an initial part of #3465.

Authors: Marcin Szamotulski
Basically, if I connect to someone and someone connects to me, before the connect returns (and before the remote accept returns as well) the local accept can return first masking itself as the remote one because we have no way to distinguish directions.
@bolt12 bolt12 force-pushed the bolt12/p2p-master-validate-transition-order branch from e6c69cc to 94c4b30 Compare November 2, 2021 14:49
@bolt12 bolt12 merged commit f10648c into p2p-master Nov 2, 2021
@iohk-bors iohk-bors bot deleted the bolt12/p2p-master-validate-transition-order branch November 2, 2021 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants