20 Commits

Author SHA1 Message Date
Marek Siarkowicz
5959110f4a Implement Compaction support in robustness test
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-06-07 10:33:57 +02:00
Marek Siarkowicz
b883f839f1 Add tests to serializable operations validation
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-05-08 12:29:55 +02:00
Marek Siarkowicz
2de719dea4 Use WAL persisted request to validate watch
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-25 21:11:37 +02:00
Marek Siarkowicz
fa9e9504ad Handle watch responses with error
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-21 20:49:49 +02:00
Marek Siarkowicz
a097a3b39d
Merge pull request #17810 from serathius/robustness-revisions-between-progress
Validate revisions between progress notify
2024-04-21 20:04:25 +02:00
Marek Siarkowicz
964680c8d0 Validate delivery of events between progress notifies
Simplifying bookmarkable to just validate revision order between events
and progress notifies.

Use reliable to validate if events are missing, but still report
broken resumable if first event after revision is missing. It's easier
to have one place that validates event slices.

Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-19 10:42:54 +02:00
Marek Siarkowicz
5a8c8b703b
Merge pull request #17807 from serathius/robustness-resumable-revision-zero
Resumable handles watch with revision zero
2024-04-16 19:41:53 +02:00
Marek Siarkowicz
dc187ce6e8 Validate bookmarkable checks the last event before progress notify
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-16 09:17:40 +02:00
Marek Siarkowicz
94a47a7cbd Resumable handles watch with revision zero
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-15 20:23:51 +02:00
Marek Siarkowicz
042e7d1a0c Add filter validation to ensure watch only includes events within selector
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-15 20:05:08 +02:00
Marek Siarkowicz
a95a307698 Add tests to watch validation
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-14 21:38:03 +02:00
Marek Siarkowicz
569693be8d Utilize WAL to patch operation history
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-14 12:09:38 +02:00
Marek Siarkowicz
6cb4c3f90d Document re-evaluating existing robustness test reports
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-08 16:58:12 +02:00
Marek Siarkowicz
e2bb8c698f Limit a timeout in testing robustness validation
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2024-04-06 12:28:57 +02:00
thirdkeyword
fbda591866 fix some typos
Signed-off-by: thirdkeyword <fliterdashen@gmail.com>
2024-03-25 10:34:44 +08:00
Madhav Jivrajani
cdd018ad2a tests/robustness: add a robustness test for validating create events
Split off valdiating create events from the prevKV test.
The added test tests the following two:
- A create event should not exist in our past history
- A non-create event should exist in our past history

Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
2024-02-14 16:28:44 +05:30
Madhav Jivrajani
9aad6700d5 tests/robustness: add robustness test for watch with PrevKV()
Kubernetes relies on the PrevKV() option in the watches it opens
against etcd. This commit adds a robustness test to validate the
same.

A watch response returned with PrevKV() is valid if:
The value in current event's prevKV matches the previous
event's value of the same key if this is not a create event.

There are cases where there can be a prevKV for a create event
as well, for example if a watch is opened after the key is creatd.
Since we don't simulate for that, we don't check for that.

Further, this adjusts revision numbers such that we can successfully create
a new replay. Needed now since we will have unit tests with
and without PrevKV co-existing and we requite creation of a
new replay everytime we validate PrevKV.

We also regenerate test data with so that prevKV exists in it

Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
2024-02-13 22:55:57 +05:30
Marek Siarkowicz
b02798e946 Refactor and reorder validation to avoid reporting multiple corelated failures
It doesn't make sense to report watch failure if key value operations
are not linearizable.

Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2023-10-13 14:06:13 +02:00
Marek Siarkowicz
c2655b4112 Fix watch validation assuming that client requesting older watch revision
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2023-10-05 14:09:43 +02:00
Marek Siarkowicz
11da84a1d1 tests/robustness: Implement loading client reports
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
2023-06-28 15:35:17 +02:00