Skip to content

Skip flaky test cases in client-eviction.tcl when in TLS mode#3151

Merged
zuiderkwast merged 1 commit into
valkey-io:unstablefrom
zhijun42:tls-flakiness
Feb 3, 2026
Merged

Skip flaky test cases in client-eviction.tcl when in TLS mode#3151
zuiderkwast merged 1 commit into
valkey-io:unstablefrom
zhijun42:tls-flakiness

Conversation

@zhijun42

@zhijun42 zhijun42 commented Feb 2, 2026

Copy link
Copy Markdown
Contributor

Closes #3146

The following two test cases are flaky

  • evict clients only until below limit - uses exact math expecting exactly half the clients evicted
  • evict clients in right order (large to small) - uses exact math expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested (client eviction) doesn't change based on TLS vs non-TLS.

The decrease maxmemory-clients causes client eviction test case could potentially be flaky as well (has not shown flakiness on CI yet), but since it has more tolerant assertion: connected_clients > 0 && connected_clients < $client_count, I think it's okay not to bother skipping it.

Other test cases are not flaky because they use large thresholds or check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
@zhijun42 zhijun42 changed the title Skip flaky test cases client-eviction.tcl in TLS mode Skip flaky test cases in client-eviction.tcl when in TLS mode Feb 2, 2026
@zhijun42

zhijun42 commented Feb 2, 2026

Copy link
Copy Markdown
Contributor Author

cc @zuiderkwast

@codecov

codecov Bot commented Feb 2, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.91%. Comparing base (3ea5cb3) to head (150566b).
⚠️ Report is 2 commits behind head on unstable.

Additional details and impacted files
@@             Coverage Diff              @@
##           unstable    #3151      +/-   ##
============================================
+ Coverage     74.83%   74.91%   +0.08%     
============================================
  Files           129      129              
  Lines         71208    71208              
============================================
+ Hits          53292    53349      +57     
+ Misses        17916    17859      -57     

see 19 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@enjoy-binbin enjoy-binbin added the run-extra-tests Run extra tests on this PR (Runs all tests from daily except valgrind and RESP) label Feb 2, 2026
@github-actions github-actions Bot removed the run-extra-tests Run extra tests on this PR (Runs all tests from daily except valgrind and RESP) label Feb 2, 2026
@zuiderkwast zuiderkwast merged commit d64f207 into valkey-io:unstable Feb 3, 2026
66 of 67 checks passed
@github-project-automation github-project-automation Bot moved this to To be backported in Valkey 8.1 Feb 3, 2026
@github-project-automation github-project-automation Bot moved this to To be backported in Valkey 8.0 Feb 3, 2026
@zuiderkwast zuiderkwast moved this to To be backported in Valkey 7.2 Feb 3, 2026
roshkhatri pushed a commit to roshkhatri/valkey that referenced this pull request Feb 3, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
@roshkhatri roshkhatri moved this from To be backported to 8.1.6 in Valkey 8.1 Feb 4, 2026
@roshkhatri roshkhatri moved this from To be backported to 8.0.7 in Valkey 8.0 Feb 4, 2026
roshkhatri pushed a commit to roshkhatri/valkey that referenced this pull request Feb 4, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
roshkhatri pushed a commit to roshkhatri/valkey that referenced this pull request Feb 4, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
@roshkhatri roshkhatri moved this from To be backported to 7.2.12 in Valkey 7.2 Feb 4, 2026
roshkhatri pushed a commit to roshkhatri/valkey that referenced this pull request Feb 4, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
roshkhatri pushed a commit to roshkhatri/valkey that referenced this pull request Feb 18, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
roshkhatri pushed a commit to roshkhatri/valkey that referenced this pull request Feb 19, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
harrylin98 pushed a commit to harrylin98/valkey_forked that referenced this pull request Feb 19, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
roshkhatri pushed a commit to roshkhatri/valkey that referenced this pull request Feb 20, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
hpatro pushed a commit that referenced this pull request Feb 24, 2026
Closes #3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
madolson pushed a commit that referenced this pull request Feb 24, 2026
Closes #3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
madolson pushed a commit that referenced this pull request Feb 24, 2026
Closes #3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
hpatro pushed a commit to hpatro/valkey that referenced this pull request Mar 5, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Harkrishn Patro <bunty.hari@gmail.com>
sarthakaggarwal97 added a commit to sarthakaggarwal97/valkey that referenced this pull request Apr 16, 2026
The 'client evicted due to percentage of maxmemory' test fails
intermittently under TLS because TLS buffer overhead changes memory
accounting, causing the tot-mem assertion to fail.

Same pattern as the other two tls:skip tags added by valkey-io#3151.

Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>
sarthakaggarwal97 pushed a commit to sarthakaggarwal97/valkey that referenced this pull request Apr 23, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
sarthakaggarwal97 pushed a commit to sarthakaggarwal97/valkey that referenced this pull request Apr 27, 2026
…-io#3151)

Closes valkey-io#3146

The following two test cases are flaky

- `evict clients only until below limit` - uses exact math expecting
exactly half the clients evicted
- `evict clients in right order (large to small)` - uses exact math
expecting specific clients evicted in order

It's fine to skip them in TLS because the core logic being tested
(client eviction) doesn't change based on TLS vs non-TLS.

The `decrease maxmemory-clients causes client eviction` test case could
potentially be flaky as well (has not shown flakiness on CI yet), but
since it has more tolerant assertion: `connected_clients > 0 &&
connected_clients < $client_count`, I think it's okay not to bother
skipping it.

Other test cases are not flaky because they use large thresholds or
check binary outcomes (yes/no eviction), not exact counts.

Signed-off-by: Zhijun <dszhijun@gmail.com>
Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>
(cherry picked from commit 89f221f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 7.2.12 WIP
Status: 8.0.7 (WIP)
Status: 8.1.6

Development

Successfully merging this pull request may close these issues.

Flaky test: client-eviction.tcl fails intermittently in TLS mode

5 participants