Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

HotKeysClusterTests.CanUseClusterFilter skips intermittently, hiding the assertions it exists for

オープン 初心者向け
  • 何か問題がありますか？
#3,239 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
76/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
csharp, redis
領域
testing-qa

調査の方向性

tests/StackExchange.Redis.Tests/HotKeysTests.cs から始め、特に 25 行目付近のサンプリング用セットアップ、43 行目の skip、62 行目のサンプリングに関するアサーションを確認します。Docker クラスターに対して HotKeysClusterTests.CanUseClusterFilter を繰り返し実行します。CpuByKey が空の場合でも、sample=true のケースでアサーションが断続的にスキップされなくなり、サンプリングの動作が引き続き検証されていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

HotKeysClusterTests.CanUseClusterFilter skips intermittently, so it can stop testing anything without saying so.

Noticed while comparing suite skip counts across runs on an unrelated branch: the total moved between 149 and 151 for the same code. The difference is this test, and it is not environmental flakiness in the usual sense - it is a deliberate Skip on the result being empty.

Where

tests/StackExchange.Redis.Tests/HotKeysTests.cs:43

Assert.SkipWhen(result.CpuByKey.IsEmpty, "Expected at least one CPU result"); // can be weird in CI

Observed

Three consecutive local runs of just this test, against the docker cluster, no code changes between them:

Passed!  - Failed: 0, Passed: 4, Skipped: 0
Passed!  - Failed: 0, Passed: 4, Skipped: 0
  Skipped HotKeysClusterTests.CanUseClusterFilter(sample: True) (RESP3)
Passed!  - Failed: 0, Passed: 3, Skipped: 1

Only the sample: True case is affected, which fits: it runs with sampleRatio: 3 (line 25), so the server samples one request in three and can legitimately observe nothing in the window.

Why it matters

Everything the test exists to assert comes after that line - including Assert.Equal(sample, result.IsSampled) at line 62, which is the sampling behaviour the sample: true case is specifically about. So on the runs where sampling happens to catch nothing, the test reports success-by-skipping and checks none of it.

This is the same failure shape as the vacuous assertion fixed in #3226 and the gaps closed in #3235: a test that fails open is worse than no test, because the suite stays green and the count of what actually ran is not something anyone reads.

Suggested direction

Two parts, either or both:

  • Make the window deterministic enough that a result is guaranteed - e.g. drive enough traffic through the sampled slot that one-in-three cannot miss, rather than skipping when it does.
  • Failing that, split the assertions: the ones that do not depend on CpuByKey having entries (notably IsSampled) should run regardless, so a thin sampling window narrows what is checked rather than skipping the whole test.

If the skip really is unavoidable, it should at least be loud about which assertions were not reached.

主要言語
C#
スター
6.2k
フォーク
1.6k
平均マージ
1日 4時間
マージ済み PR（30日）
29

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

StackExchange/StackExchange.Redis のほかの issue

StackExchange/StackExchange.Redis の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。