-
Notifications
You must be signed in to change notification settings - Fork 10
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: use correct index for the conclusion feed. (#561)
* refactor: update conclusion feed test to highlight bugs We found a few bugs in the conclusion feed implementation on the event service. Fixes will follow, however this change updates the test to make the bugs obvious. Bugs: 1. Indexes are duplicated 2. Unsigned event indexes are always zero 3. Off by one bug in the bounds of the highwater mark * fix: use correct delivered index The previous code would zip the parsed events with the all_blocks iterator. However the all_blocks iterator was longer than parsed and so the delivered values got misaligned with the events, causing the index of conclusion feed events to be incorrect. Now we correctly filter down the all_block iterator so it has only a single value per event. * fix: use correct delivered for unsigned init events The previous code had a typo to always use 0 as the delivered/index for unsigned init events. This is now fixed. * fix: use 1 based highwater_mark values The sqlite db uses 1 based highwater_mark values, meaning it does delivered >= highwater_mark vs delivered > highwater_mark. The conclusion feed doesn't treat the highwater mark directly but instead just returns the index and expects clients to reuse the max index they have seen which means we want an exclusive comparison. We achieve this by adding one to the highwater_mark. * refactor: make event access stateful Previously a global static delivered counter was used to assign/track delivered values. However this makes testing hard as if multiple tests run they effect the delivered values of each other. This change makes the EventAccess contain the counter state within itself and then anywhere that a pool was used to access events it was replaced with an Arc<EventAccess>. This means we can truly have isolated delivered counters. * refactor: use consistent naming of access types We have an access type pattern for structs that contain the logic to read specific tables in the db. There were called CeramicOne{Table}, with this change they are renamed to {Table}Access. The CeramicOne prefix was meaningless and the table name alone was not enough to distinguish the type from other types related to the same entities.
- Loading branch information
1 parent
a92a809
commit 052196f
Showing
21 changed files
with
599 additions
and
402 deletions.
There are no files selected for viewing
This file contains 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 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 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
Oops, something went wrong.