Refactor event dispatcher #6765
Open
+2,445
−2,219
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
The observer is now a pure data struct without any methods. All functionality lives in the dispatcher; the observer just contains the info where to send the data. This is a largely mechanical change: cut & paste; delete now duplicate `delete_payload` method; fix references.
No functional changes, only moving things around
There should be no functional change here.
Since the code in new files is just cut & paste from `event_dispatcher.rs`, I kept the same header from there, but bumped the year to 2025.
This is the final step to making `EventObserver` a "dumb" data object that simply reflects the configuration of the registered observer. Most of this change is straightforward. There is one thing that's worth a mention, and that's the `ProposalCallbackHandler`, a concept that was added in stacks-network#4228. Because block proposal validation happens on a dedicated thread, those validation events are handled a little specially. Since `send_payload` now needs a dispatcher instance as the source of the `db_path`, the list of observers alone is no longer enough. For now I've elected to simply add the DB path to the ProposalCallbackHandler and keep a non-method version of `send_payload` around that gets the DB path passed in. Eventually I may have to clone the dispatcher, but for now this approach had the smallest blast radius. There wasn't any test coverage for this special behavior (at least not on the event dispatcher side -- there are [some tests](https://github.com/stacks-network/stacks-core/blob/45381558f5e79554fc6e7930b0c4091e739e4992/stackslib/src/net/api/tests/postblock_proposal.rs#L234) on the API side of things), so I added that as well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
I started doing this as part of #6762, but since this refactoring is a self-contained change, I figured I'd split it into its own PR.
Two primary changes:
event_dispatcher.rsinto multiple files to make it easier to work with, andEventObserverinto a "dumb" struct that contains nothing more than the actual subscriber information and has no functionality of its own, with theEventDispatcherbeing the one doing the real work.I would strongly suggest reviewing commit-by-commit.
The individual commits are structured so that the largely mechanical changes (like moving code from one file to another) can be more quickly verified by diffing the code that was remove from one file with the corresponding code that was added to another. Also take not of the individual commit messages.