-
Notifications
You must be signed in to change notification settings - Fork 2
chore: setup withdrawable event queue #14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
2b3e155
add withdrawable queue
gusin13 8697bb8
withdrawn queue
gusin13 0354abf
fix
gusin13 2875aea
add state record
gusin13 51b7de1
fix state history
gusin13 e7e0311
slashed queue
gusin13 6623b6c
Revert "slashed queue"
gusin13 cf05940
fix
gusin13 7f9e78b
pr comments
gusin13 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The more I think about it, the more it feels like passing everything down via msg might have been the wrong decision.
Perhaps passing down just a staking transaction hash would be sufficient and letting the API handle the lookup instead. 🤔
I’m trying to approach this from an extensibility perspective—considering whether this approach is flexible enough to support new features in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm good question - if we let api query the db on every event, it would cause load on db no?
we don't have any db cache or something in api so all the queries would go to mongo.
so basically it boils down to
queue bandwidth(storage) vs db query load 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The queue bandwidth is fine since we’re not passing large-sized content. This is more of an extensibility concern.
For instance, if we add new metadata to the database, we can avoid modifying the queue code and instead rely on the API(or other) service to handle its own lookups.
While database load is a valid concern, MongoDB performs some internal caching for recently accessed documents. As long as the data has been accessed recently, the performance should remain reasonable.
In any case, this is neither a concern nor a blocker for this PR, in my opinion. It’s something we can revisit in the future, @kirugan, if there’s a need to redesign this communication pattern.