How Polytone Handles Channel Closure
Every note has a pair, which corresponds to the voice module that the note is connected to. This can either be set during instantiation, or note modules will pair with the first voice module they are connected to. Once paired, a note will reject all future connections to a different voice module.
This means that if a channel closes between a note and its pair, anyone can re-open the channel permissionlessly and re-enable the accounts. While a note has a pair but no channel, those accounts are paused as the note will not send any messages to control them.
To ensure that the same account will be used, even if a channel closes, the voice module generates user account addresses based on the (connection_id, note_port, user_address) triplet. This ensures that two notes on the same remote chain will have different addresses for a user, but a channel closing and being reopened (channel ID changes) won't cause the user's account to change.
The above handles channel closure, there are two remaining cases:
- Light client missbehavior freezes a light client.
- Light client expiry freezes a light client.
In both cases the behavior is the same: no packets (including timeouts) will be sendable on the connection until it is recovered by x/gov. Once x/gov restores the channel, pending timeouts will be delivered and the state machine will advance. In this sense, we can treat issues at the light client level like a pause, and don't need additional handling in Polytone.