The logic to subscribe / unsubscribe topics at a fork is the following:
network/src/service.rs holds three timer futures:
next_fork_subscriptions: Calls subscribe_new_fork_topics and subscribes to any existing topics but with the new fork-digest. Also, subscribes to new topics returned from fork_core_topics(new_fork)next_unsubscribe: Calls unsubscribe_from_fork_topics_except to unsubscribe all topics expect those with the current fork-digestnext_fork_update: Sets new futures for next_fork_subscriptions, next_unsubscribe and next_fork_update
Outside of a fork-boundary the network service may receive a SubscribeCoreTopics message and subscribe to all topics returned by core_topics_to_subscribe
With peerdas
Now we have a new topic transition point where:
- we need to unsubscribe to a topic in all fork-digests
- do not rotate topics on a new fork-digest
Note that data_columns topics are not core topics, so we may not have to subscribe ahead of time. If we can accept a few slots of instability while we find peers we can avoid the complexity.
The logic to subscribe / unsubscribe topics at a fork is the following:
network/src/service.rsholds three timer futures:next_fork_subscriptions: Callssubscribe_new_fork_topicsand subscribes to any existing topics but with the new fork-digest. Also, subscribes to new topics returned fromfork_core_topics(new_fork)next_unsubscribe: Callsunsubscribe_from_fork_topics_exceptto unsubscribe all topics expect those with the current fork-digestnext_fork_update: Sets new futures fornext_fork_subscriptions,next_unsubscribeandnext_fork_updateOutside of a fork-boundary the network service may receive a
SubscribeCoreTopicsmessage and subscribe to all topics returned bycore_topics_to_subscribeWith peerdas
Now we have a new topic transition point where:
Note that data_columns topics are not core topics, so we may not have to subscribe ahead of time. If we can accept a few slots of instability while we find peers we can avoid the complexity.