From 94e23aae12afece280f36b9afdab9e0210a2348a Mon Sep 17 00:00:00 2001
From: peter-csala <57183693+peter-csala@users.noreply.github.com>
Date: Sun, 29 Oct 2023 16:00:14 +0100
Subject: [PATCH] [Docs] Fix the policywrap sample (#1728)

* Fix the policywrap sample

* Fix arrows

* Wrap related comments are fixed
---
 docs/migration-v8.md                | 18 +++++++++---------
 src/Snippets/Docs/Migration.Wrap.cs | 14 +++++++-------
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/docs/migration-v8.md b/docs/migration-v8.md
index 175d332de9d..8b44e18e651 100644
--- a/docs/migration-v8.md
+++ b/docs/migration-v8.md
@@ -156,10 +156,10 @@ IAsyncPolicy retryPolicy = Policy.Handle<Exception>().WaitAndRetryAsync(3, _ =>
 
 IAsyncPolicy timeoutPolicy = Policy.TimeoutAsync(TimeSpan.FromSeconds(3));
 
-// Wrap the policies. The policies are executed in the following order (i.e. Last-In-First-Out):
-// 1. Retry
-// 2. Timeout
-IAsyncPolicy wrappedPolicy = Policy.WrapAsync(timeoutPolicy, retryPolicy);
+// Wrap the policies. The policies are executed in the following order:
+// 1. Retry <== outer
+// 2. Timeout <== inner
+IAsyncPolicy wrappedPolicy = Policy.WrapAsync(retryPolicy, timeoutPolicy);
 ```
 <!-- endSnippet -->
 
@@ -169,9 +169,9 @@ In v8, there's no need to use policy wrap explicitly. Instead, policy wrapping i
 
 <!-- snippet: migration-policy-wrap-v8 -->
 ```cs
-// The "PolicyWrap" is integrated directly. Strategies are executed in the same order as they were added (i.e. First-In-First-Out):
-// 1. Retry
-// 2. Timeout
+// The "PolicyWrap" is integrated directly. The strategies are executed in the following order:
+// 1. Retry <== outer
+// 2. Timeout <== outer
 ResiliencePipeline pipeline = new ResiliencePipelineBuilder()
     .AddRetry(new()
     {
@@ -185,8 +185,8 @@ ResiliencePipeline pipeline = new ResiliencePipelineBuilder()
 ```
 <!-- endSnippet -->
 
-> [!IMPORTANT]
-> In v7, the policy wrap ordering is different; the policy added first was executed last (FILO). In v8, the execution order matches the order in which they were added (FIFO). See [fallback after retries](strategies/fallback.md#fallback-after-retries) for an example on how the strategies are executed.
+> [!NOTE]
+> See [fallback after retries](strategies/fallback.md#fallback-after-retries) for an example on how the strategies are executed.
 
 ## Migrating retry policies
 
diff --git a/src/Snippets/Docs/Migration.Wrap.cs b/src/Snippets/Docs/Migration.Wrap.cs
index 4563953f68b..af7c08162a9 100644
--- a/src/Snippets/Docs/Migration.Wrap.cs
+++ b/src/Snippets/Docs/Migration.Wrap.cs
@@ -10,10 +10,10 @@ public static void PolicyWrap_V7()
 
         IAsyncPolicy timeoutPolicy = Policy.TimeoutAsync(TimeSpan.FromSeconds(3));
 
-        // Wrap the policies. The policies are executed in the following order (i.e. Last-In-First-Out):
-        // 1. Retry
-        // 2. Timeout
-        IAsyncPolicy wrappedPolicy = Policy.WrapAsync(timeoutPolicy, retryPolicy);
+        // Wrap the policies. The policies are executed in the following order:
+        // 1. Retry <== outer
+        // 2. Timeout <== inner
+        IAsyncPolicy wrappedPolicy = Policy.WrapAsync(retryPolicy, timeoutPolicy);
 
         #endregion
     }
@@ -22,9 +22,9 @@ public static void PolicyWrap_V8()
     {
         #region migration-policy-wrap-v8
 
-        // The "PolicyWrap" is integrated directly. Strategies are executed in the same order as they were added (i.e. First-In-First-Out):
-        // 1. Retry
-        // 2. Timeout
+        // The "PolicyWrap" is integrated directly. The strategies are executed in the following order:
+        // 1. Retry <== outer
+        // 2. Timeout <== outer
         ResiliencePipeline pipeline = new ResiliencePipelineBuilder()
             .AddRetry(new()
             {