-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
WIP: test if watch is sequential #18264
base: main
Are you sure you want to change the base?
Conversation
Hi @ah8ad3. Thanks for your PR. I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
1aa13de
to
9347f8e
Compare
9347f8e
to
caaf1f0
Compare
Printed the revisions it seems not checking revision 0 is not working here
First one is 2 and revision is incremental. |
@@ -143,3 143,27 @@ external: | |||
t.Errorf("Progress notify does not match, expect: %v, got: %v", expectProgressNotify, gotProgressNotify) | |||
} | |||
} | |||
|
|||
func validateWatchSequential(t *testing.T, reports []report.ClientReport) { | |||
for _, r := range reports { |
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.
What about 2 concurrent client watch requests to the same server? I think we need to process in different order than reports. I think we should only consider watch requests if they don't intersect in time.
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 solution came to my mind is to create a list of all WatchResponse
that got sorted by Time.
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.
I would recommend to collect (per member) pairs (last revision, time) from watch responses and sort them by time. Then go through all watch requests and search the (last revision, time) to find the last one before sending the request. First event revision should be always greater or equal one we found.
Can you please take another look? @serathius |
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Please rebase |
…ial to check memberID in events Signed-off-by: ah8ad3 <[email protected]>
…revision based one time of response Signed-off-by: ah8ad3 <[email protected]>
a6ec18c
to
f7c6c33
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ah8ad3 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Done, PTAL @serathius At end i will squash. |
WIP:
Added member id in
WatchResponse
.Change
validateOrdered
to check forMemberId
for each event, as sequential should check for each process.Fixes #18141