Follow-up tracking for items called out in PR #1398 (merged) and its review. The merged fix replays mcache from _handle_new_peer when a peer's subscription is processed before the outbound pubsub stream exists.
Disconnect / reconnect hygiene
_handle_dead_peer early return (pubsub.py): when peer_id not in self.peers, the handler returns before peer_topics cleanup, so a peer that drops while half-registered can leave stale peer_topics entries.- Reconnect replay:
_send_recent_messages_to_new_peer has no was_newly_added guard (unlike handle_subscription). After a messy disconnect + reconnect, a peer may receive a full mcache window again even when subscriptions were not newly announced. Mitigation today is mostly receiver seen-cache dedup; sender-side gating may be desirable once disconnect cleanup is fixed.
Deeper fix (separate design)
Maintainability
IPubsubRouter: declare optional/async hooks for send_recent_messages and flush_pending_messages instead of additional hasattr(self.router, ...) probes in pubsub.py.
Tests (optional)
- Tighten
test_publish_before_identify_with_subscription_before_stream timing (currently ~7s+) with predicate-based wait_for helpers if available elsewhere in pubsub tests.
Context
- Original flake:
test_publish_before_identify_completes under pytest -n auto (real message-loss race, not a bad test).
- No separate tracking issue existed before merge; newsfragment
1398.bugfix.rst used PR number per newsfragments/README.md.
/cc @gmelodie
Follow-up tracking for items called out in PR #1398 (merged) and its review. The merged fix replays mcache from
_handle_new_peerwhen a peer's subscription is processed before the outbound pubsub stream exists.Disconnect / reconnect hygiene
_handle_dead_peerearly return (pubsub.py): whenpeer_id not in self.peers, the handler returns beforepeer_topicscleanup, so a peer that drops while half-registered can leave stalepeer_topicsentries._send_recent_messages_to_new_peerhas nowas_newly_addedguard (unlikehandle_subscription). After a messy disconnect + reconnect, a peer may receive a full mcache window again even when subscriptions were not newly announced. Mitigation today is mostly receiver seen-cache dedup; sender-side gating may be desirable once disconnect cleanup is fixed.Deeper fix (separate design)
GossipSub.publishqueueing: peers known only via in-flight connection setup may still be in neitherpubsub.peersnorpeer_topicsat publish time, so nothing is queued in_pending_messages. PR fix(pubsub): replay recent messages once a peer's outbound stream is registered聽#1398 patched the recovery path only; changing queueing semantics affects all pubsub users.Maintainability
IPubsubRouter: declare optional/async hooks forsend_recent_messagesandflush_pending_messagesinstead of additionalhasattr(self.router, ...)probes inpubsub.py.Tests (optional)
test_publish_before_identify_with_subscription_before_streamtiming (currently ~7s+) with predicate-basedwait_forhelpers if available elsewhere in pubsub tests.Context
test_publish_before_identify_completesunderpytest -n auto(real message-loss race, not a bad test).1398.bugfix.rstused PR number pernewsfragments/README.md./cc @gmelodie