Remove WaitActive
state during negotiation
#1722
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Staged on top of #1721
The
WaitActive
state has outlived its usefulness.Right now, there are two wait points in the Upstair's client task:
client_connect_tx/rx
) to be fired before connecting to the DownstairsYesItsMe
from the downstairs, it waits for the upstairs to be activated before sendingPromoteToActive
. This is implemented through a runtime check when it reaches theWaitForActive
stateIt turns out that these two things always happen together; there's no case where we want to connect to a Downstairs, get to
YesItsMe
, then not promote it to active.This PR removes the
WaitActive
state, moving straight fromStart
toWaitForPromote
once the connection oneshot fires. I believe this fixes the (hypothetical) panic proposed in #1721, although I haven't written out a unit test for it.Most of the LOC changes are removing the increasingly-outdated block comment about negotiation; it's all nicely represented the
NegotiationState
docstring, which has been kept up to date.