diff --git a/docs/chaos/index.md b/docs/chaos/index.md index adbe999fba..af5d5d466e 100644 --- a/docs/chaos/index.md +++ b/docs/chaos/index.md @@ -47,13 +47,14 @@ builder .AddChaosBehavior(behaviorInjectionRate, cancellationToken => RestartRedisAsync(cancellationToken)); // Inject a chaos behavior to executions ``` +> [!NOTE] +> It is usual to place the chaos strategy as the last strategy in the resilience pipeline. +> By placing the chaos strategies as last, they subvert the usual outbound call at the last minute, substituting their fault or adding extra latency, etc. +> The existing resilience strategies - further out in the `ResiliencePipeline` - still apply, so you can test how the Polly resilience strategies you have configured handle the chaos/faults injected by Simmy. -- It is usual to place the chaos strategy as the last strategy in the resilience pipeline. -- By placing the chaos strategies as last, they subvert the usual outbound call at the last minute, substituting their fault or adding extra latency, etc. -- The existing resilience strategies - further out in the `ResiliencePipeline` - still apply, so you can test how the Polly resilience strategies you have configured handle the chaos/faults injected by Simmy. - -- The `AddChaos*` will take effect sequentially if you combine them together. -- In the above example, we use **fault first then latency strategy**, it can save fault waiting time. If you put `AddChaosLatency` before `AddChaosFault`, you will get different behavior. +> [!NOTE] +> The `AddChaosFault` `AddChaosLatency` `AddChaosOutcome` `AddChaosBehavior` will take effect sequentially if you combine them together. +> In the above example, we use **fault first then latency strategy**, it can save fault waiting time. If you put `AddChaosLatency` before `AddChaosFault`, you will get different behavior. ```mermaid sequenceDiagram