-
Notifications
You must be signed in to change notification settings - Fork 98
Remove tickets that are within an aggregated ticket prior to sending aggregation request #6433
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
Conversation
WalkthroughWalkthroughThe recent changes enhance ticket management functionality by modifying how redeemable tickets are accessed and processed. Key adjustments include transitioning from single-index to multi-index handling within the Changes
Assessment against linked issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
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.
Actionable comments posted: 0
Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Files ignored due to path filters (1)
Cargo.lock
is excluded by!**/*.lock
Files selected for processing (3)
- chain/actions/src/redeem.rs (1 hunks)
- db/api/src/ticket_manager.rs (2 hunks)
- db/api/src/tickets.rs (31 hunks)
Additional comments not posted (11)
db/api/src/ticket_manager.rs (1)
Line range hint
150-159
:
LGTM! Cloning theselector
variable ensures thread safety and prevents unintended side effects.The change improves the control flow by allowing the asynchronous operation to operate on a clone of the selector, which is crucial in concurrent environments.
chain/actions/src/redeem.rs (1)
137-137
: LGTM! Cloning theselector
variable ensures ownership and borrowing safety.The change guarantees that the original selector remains intact and can be used elsewhere without risk of modification or invalidation.
db/api/src/tickets.rs (9)
16-17
: New imports are necessary.The new imports from
sea_orm
andsea_query
are required for the changes in theTicketSelector
structure and methods.
65-69
: Update toDisplay
implementation is approved.The
Display
implementation has been updated to correctly format theindex
field when it contains multiple values.
92-92
: Update tois_unique
method is approved.The
is_unique
method now checks if the length of theindex
vector is one, ensuring correct identification of a single ticket selection.
95-98
: Update towith_index
method is approved.The
with_index
method has been modified to push the index into theself.index
vector, allowing for the selection of multiple tickets.
126-126
: Update toFrom<&AcknowledgedTicket>
implementation is approved.The
From<&AcknowledgedTicket>
implementation now initializesindex
asvec![value.ticket.index]
, ensuring correct initialization.
157-158
: Update toIntoCondition
implementation is approved.The
IntoCondition
implementation has been updated to correctly handle multiple indices using theis_in
method.
1412-1417
: Update togenerate_random_ack_ticket
function is approved.The
generate_random_ack_ticket
function now includes anindex_offset
parameter, enhancing its flexibility.
2452-2503
: New test case is approved.The new test case validates the behavior of ticket aggregation when duplicates are present, ensuring the integrity of the ticketing system.
40-51
: Change toTicketSelector
structure is approved.The
index
field in theTicketSelector
struct has been changed fromOption<u64>
toVec<u64>
, allowing for the selection of multiple tickets.However, ensure that all usages of the
TicketSelector
structure in the codebase are updated to reflect this change.Verification successful
Ensure all usages of
TicketSelector
are updated.The
TicketSelector
structure has been updated, but we need to verify that all instances in the codebase correctly reflect the change fromOption<u64>
toVec<u64>
. This includes proper initialization and usage of theindex
field.
All usages of
TicketSelector
have been updated.The
index
field in theTicketSelector
struct has been updated fromOption<u64>
toVec<u64>
, and all relevant instances in the codebase reflect this change.
protocol.rs
ticket_manager.rs
tickets.rs
redeem.rs
handlers.rs
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all usages of the `TicketSelector` structure in the codebase. # Test: Search for the `TicketSelector` structure. Expect: Only occurrences of the new structure. rg --type rust -A 5 $'TicketSelector'Length of output: 18920
Script:
#!/bin/bash # Description: Verify the initialization and usage of the `index` field in `TicketSelector`. # Search for the initialization of `TicketSelector` and check the usage of the `index` field. rg --type rust 'TicketSelector::new\(' -A 5 rg --type rust 'TicketSelector::from\(' -A 5 rg --type rust '\.with_index\(' -A 5Length of output: 11341
In certain situations, the database can contain an aggregated ticket and also a ticket that is inside this aggregation ticket.
E.g. the DB contains a ticket with Index 1 and Offset 4, but also a ticket with Index 3, Offset 1.
This can happen when packets are arriving out of order, and only e.g. a single ticket is needed to trigger an aggregation.
Example:
This results in tickets: (2,1), (3,1) and (0,5) being in the DB, which have overlapping index intervals. This will subsequently result in aggregation failure, when another aggregation attempt is made.
This PR fixes the issue by removing the single tickets that overlap with an aggregated ticket (marking them as neglected).
However, this comes at certain loss. This cannot be prevented unless more sophisticated buffering algorithm is introduced before the aggregation takes place.
An ultimate solution is to get rid of aggregation completely, which is planned for future releases.
Closes #6419