tests/e2e: add e2e test to reproduce issue 18089 #18201
Conversation
|
/assign @serathius @ahrtr @siyuanfoundation @jmhbnz @fuweid |
MadhavJivrajani
force-pushed
the
e2e-issue-18089
branch
from
6b29dd0
to
de25fcc
Compare
|
/retest |
|
/test all |
MadhavJivrajani
force-pushed
the
e2e-issue-18089
branch
from
de25fcc
to
d9d4977
Compare
|
Very nice! Thank you @MadhavJivrajani |
|
cc @ahrtr |
|
Please fix |
| // - PUT k v3 (assume returned revision = r3) | ||
| // - PUT k v4 (assume returned revision = r4) | ||
| // - DELETE k (assume returned revision = r5) | ||
| // - PUT k v6 (assume returned revision = r6) |
There was a problem hiding this comment.
Side note: Even if there is not new revision for K, the DELETE event is missing as well.
There was a problem hiding this comment.
Thinking if we could use a modelReplay from robustness to provide a clearer explanation of expectations for the results.
There was a problem hiding this comment.
@serathius could you elaborate?
There was a problem hiding this comment.
Thinking if we could use a modelReplay from robustness to provide a clearer explanation of expectations for the results.
NO.
Robustness testing is characterized by randomness and is often conducted under high traffic conditions. But this is just a very corner case, which should be covered by e2e or integration test.
There was a problem hiding this comment.
Robustness testing is characterized by randomness and is often conducted under high traffic conditions.
Heh, I said modelReplay, which is deterministic stub of etcd.
There was a problem hiding this comment.
I said modelReplay, which is deterministic stub of etcd.
Not sure we are talking about the same thing.
My understanding is the existing check on watch API guarantee should be already good enough, otherwise this issue could't be reproduced by robustness test.
Any specific additional check for such corner case isn't reasonable to be added into robustness test.
MadhavJivrajani
force-pushed
the
e2e-issue-18089
branch
2 times, most recently
from
f05cde7
to
22aee25
Compare
|
Can we add the test case into |
The goal is to reproduce a DELETE event being dropped in a watch after a compaction occurs on the revision where the deletion took place. In order to reproduce this, we perform the following sequence (steps for reproduction thanks to @ahrtr): - PUT k v2 (assume returned revision = r2) - PUT k v3 (assume returned revision = r3) - PUT k v4 (assume returned revision = r4) - DELETE k (assume returned revision = r5) - PUT k v6 (assume returned revision = r6) - COMPACT r5 - WATCH rev=r5 We should get the DELETE event (r5) followed by the PUT event (r6). However, currently we only get the PUT event with returned revision of r6 (key=k, val=v6). Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
MadhavJivrajani
force-pushed
the
e2e-issue-18089
branch
from
22aee25
to
ebf2cac
Compare
|
@ahrtr can you PTAL again? |
|
/retest |
1 similar comment
|
/retest |
e2e for #18089
The goal is to reproduce a DELETE event being dropped in a watch after a compaction occurs on the revision where the deletion took place. In order to reproduce this, we perform the following sequence (steps for reproduction thanks to @ahrtr):
We should get the DELETE event (r5) followed by the PUT event (r6). However, currently we only get the PUT event with returned revision of r6 (key=k, val=v6).
/assign @ahrtr @serathius @siyuanfoundation