Thread-Safe Stream Removal Info #4905
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mur-me
approved these changes
Jun 6, 2025
Frozen
approved these changes
Jun 9, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR introduces several improvements to the stream management system, focusing on ensuring correctness and thread safety in scenarios involving stream removal, discovery. One of the key changes is the thread-safe handling of
RemovalInfoupdates. Previously, there was a risk of concurrent modifications leading to incorrect removal state tracking. By ensuring that access toRemovalInfois synchronized and consistent, we reduce the chance of re-adding a stream that was just removed or still in cooldown, improving the resilience of the system during peer churn.Additionally, the discovery process was updated to respect the state of
removedStreams. Now, before attempting to add a new stream, the system checks whether it has been recently removed and is still within a cooldown window. This prevents the unnecessary or premature reuse of streams that are not ready to be re-established, preserving system stability and stream lifecycle integrity.The protocol stream counter (
numByProto) is also updated more defensively. Counters are now only incremented or decremented after confirming that the corresponding stream was validly added or removed. This change prevents incorrect metrics or internal misreporting that could arise if the counter is blindly mutated, especially in edge cases involving duplicate or stale stream data.Finally, the cleanup process was improved by ensuring that removed streams are also deleted from the reserved list. This change prevents memory leaks and dangling stream references, ensuring that once a stream is removed from the system, all internal references are cleaned up consistently.