Fixed-in-version regression check discards every event in the batch, including the regressing event
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 74/100
調査の方向性
Read src/Exceptionless.Core/Pipeline/030_CheckForRegressionAction.cs around lines 50–80 and the existing EnsureVersionedRegressionAsync test. Trace how version groups are ordered and how discarded contexts skip later pipeline actions; then add a pipeline test with the older event dated before the newer one. Done means only the older-version event is discarded and the newer event is saved as the regression with notifications queued.
索引モデルが issue の本文から書いたものです。
説明
When a stack is marked fixed in a version and a batch has an event older than that version, CheckForRegressionAction discards every event for the stack in that batch, not just the older version's events. If the batch also contains a newer-version event, the stack is still marked regressed, but the event that caused the regression is discarded, so it isn't saved and no regression notification or webhook is sent.
Where
030_CheckForRegressionAction.cs#L50-L80
foreach (var versionGroup in versions)
{
var version = ...;
if (version < fixedInVersion)
{
foreach (var ctx in stackGroup.Where(s => s.Organization.HasPremiumFeatures)) // should be versionGroup
{
ctx.IsDiscarded = true;
ctx.IsCancelled = true;
}
continue;
}
regressedVersion = version;
regressedContext = versionGroup.First();
break;
}
What happens
For a paid organization, with a stack fixed in 1.0.1 and one batch that contains 1.0.0 (earlier date) and 1.0.2 (later date) events for that stack:
- Groups are ordered by event date, so the
1.0.0group is checked first. The inner loop iteratesstackGroup, so both events are marked discarded and cancelled. - The loop continues to
1.0.2, which setsregressedContext. The stack is saved asRegressedand that context getsIsRegression = true. - The context is already cancelled, so later pipeline actions skip it (PipelineBase.cs#L62). The event isn't stored, and
QueueNotificationActionnever queues the regression notification or theStackRegressionwebhook.
The result also depends on order. If the newer event is earlier in the batch, the loop breaks on it before reaching the older group, so the older-version events are kept rather than discarded.
The existing test EnsureVersionedRegressionAsync puts the regressing event first by date, so it doesn't cover this case.
Expected
Only events older than the fixed version are discarded. A newer-version event in the same batch is saved, flagged as the regression, and triggers notifications.
Suggested fix
Iterate versionGroup instead of stackGroup when discarding. Evaluate every version group rather than breaking on the first regression, so older-version events later in the batch are discarded consistently. Add a pipeline test with an older-version event dated before a newer-version event.
- 主要言語
- C#
- スター
- 2.5k
- フォーク
- 508
- 平均マージ
- 2日 17時間
- マージ済み PR(30日)
- 40
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
exceptionless/Exceptionless のほかの issue
-
bug documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
exceptionless/Exceptionless#2707 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
exceptionless/Exceptionless#2706 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
exceptionless/Exceptionless#2705 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
exceptionless/Exceptionless#2704 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
exceptionless/Exceptionless#2703 ·
メンテナーはふだん 1 日以内に返信
exceptionless/Exceptionless の issue をすべて見る