blockers

Signed-off-by: Hannah Hunter <[email protected]>

Author: hhunter-ms

articles/azure-functions/durable/durable-functions-azure-storage-provider.md

@@ -232,7 +232,7 @@ Keep these considerations in mind when choosing the storage account for your Dur
 
 - For performance-sensitive workloads, configure a storage account other than the default account (`AzureWebJobsStorage`). Since Durable Functions uses Azure Storage heavily, using a dedicated storage account isolates Durable Functions storage usage from the internal usage by the Azure Functions host.
 - You need standard general purpose Azure Storage accounts when using the Azure Storage provider. All other storage account types aren't currently supported. 
-- Legacy v1 general purpose storage accounts for Durable Functions is recommended. The newer v2 storage accounts can be more expensive for Durable Functions workloads. [Learn more about Azure Storage account types](../../storage/common/storage-account-overview.md).
+- Legacy v1 general purpose storage accounts for Durable Functions are recommended. The newer v2 storage accounts can be more expensive for Durable Functions workloads. [Learn more about Azure Storage account types](../../storage/common/storage-account-overview.md).
 
 ## Orchestrator scale-out
 

articles/azure-functions/durable/durable-functions-perf-and-scale.md

@@ -166,7 +166,7 @@ The following table shows which queues each storage provider partitions and the
 | **Documentation** | See [Orchestrator scale-out](durable-functions-azure-storage-provider.md#orchestrator-scale-out) | See [Partition count considerations](https://microsoft.github.io/durabletask-netherite/#/settings?id=partition-count-considerations) | n/a |
 
 > [!WARNING]
-> You can't change the partition count after you create a task hub. Set it high enough to meet expected scale out requirements for the task hub instance.
+> You can't change the partition count after you create a task hub. Set it high enough to meet expected scale-out requirements for the task hub instance.
 
 ### Configure partition count
 

articles/azure-functions/durable/durable-functions-task-hubs.md

@@ -192,33 +192,33 @@ After this orchestration is initiated by a client, the application processes it
 
 1. A client requests to start a new orchestration with instance-id "123". After the client completes this request, the task hub contains a placeholder for the orchestration state and an instance message:
 
-  :::image type="content" source="./media/durable-functions-task-hubs/work-items-1.png" alt-text="workitems-illustration-step-1":::
+  :::image type="content" source="./media/durable-functions-task-hubs/work-items-1.png" alt-text="Diagram showing task hub state after orchestration start request (step 1).":::
 
    The label `ExecutionStarted` is one of many [history event types](https://github.com/Azure/durabletask/tree/main/src/DurableTask.Core/History#readme) that identify the various types of messages and events participating in an orchestration's history.
 
 2. A worker executes an *orchestrator work item* to process the `ExecutionStarted` message. It calls the orchestrator function which starts executing the orchestration code. This code schedules two activities and then stops executing when it is waiting for the results. After the worker commits this work item, the task hub contains
 
-  :::image type="content" source="./media/durable-functions-task-hubs/work-items-2.png" alt-text="workitems-illustration-step-2":::
+  :::image type="content" source="./media/durable-functions-task-hubs/work-items-2.png" alt-text="Diagram showing task hub state after first orchestrator work item commit (step 2).":::
 
    The runtime state is now `Running`, two new `TaskScheduled` messages were added, and the history now contains the five events `OrchestratorStarted`, `ExecutionStarted`, `TaskScheduled`, `TaskScheduled`, `OrchestratorCompleted`. These events represent the first episode of this orchestration's execution.
 
 3. A worker executes an *activity work item* to process one of the `TaskScheduled` messages. It calls the activity function with input "2". When the activity function completes, it creates a `TaskCompleted` message containing the result. After the worker commits this work item, the task hub contains
 
-  :::image type="content" source="./media/durable-functions-task-hubs/work-items-3.png" alt-text="workitems-illustration-step-3":::
+  :::image type="content" source="./media/durable-functions-task-hubs/work-items-3.png" alt-text="Diagram showing task hub state after first activity work item commit (step 3).":::
 
 4. A worker executes an *orchestrator work item* to process the `TaskCompleted` message. If the orchestration is still cached in memory, it can just resume execution. Otherwise, the worker first [replays the history to recover the current state of the orchestration](durable-functions-orchestrations.md#reliability). Then it continues the orchestration,  delivering the result of the activity. After receiving this result, the orchestration is still waiting for the result of the other activity, so it once more stops executing. After the worker commits this work item, the task hub contains
 
-  :::image type="content" source="./media/durable-functions-task-hubs/work-items-4.png" alt-text="workitems-illustration-step-4":::
+  :::image type="content" source="./media/durable-functions-task-hubs/work-items-4.png" alt-text="Diagram showing task hub state after second orchestrator work item commit (step 4).":::
 
    The orchestration history now contains three more events `OrchestratorStarted`, `TaskCompleted`, `OrchestratorCompleted`. These  events represent the second episode of this orchestration's execution.
 
 5. A worker executes an *activity work item* to process the remaining `TaskScheduled` message. It calls the activity function with input "1". After the worker commits this work item, the task hub contains
 
-  :::image type="content" source="./media/durable-functions-task-hubs/work-items-5.png" alt-text="workitems-illustration-step-5":::
+  :::image type="content" source="./media/durable-functions-task-hubs/work-items-5.png" alt-text="Diagram showing task hub state after second activity work item commit (step 5).":::
 
 6. A worker executes another *orchestrator work item* to process the `TaskCompleted` message. After receiving this second result, the orchestration completes. After the worker commits this work item, the task hub contains
 
-  :::image type="content" source="./media/durable-functions-task-hubs/work-items-6.png" alt-text="workitems-illustration-step-6":::
+  :::image type="content" source="./media/durable-functions-task-hubs/work-items-6.png" alt-text="Diagram showing task hub state after final orchestrator work item commit (step 6).":::
 
    The runtime state is now `Completed`, and the orchestration history now contains four more events `OrchestratorStarted`, `TaskCompleted`, `ExecutionCompleted`, `OrchestratorCompleted`. These events represent the third and final episode of this orchestration's execution.
 

articles/azure-functions/durable/durable-functions-zero-downtime-deployment.md

@@ -50,7 +50,7 @@ For detailed configuration and implementation guidance, see [Orchestration versi
 
 Define new versions of your functions and leave the old versions in your function app. As you can see in the diagram, a function's version becomes part of its name. Because previous versions of functions are preserved, in-flight orchestration instances can continue to reference them. Meanwhile, requests for new orchestration instances call for the latest version, which your orchestration client function can reference from an app setting.
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/versioning-strategy.png" alt-text="Versioning strategy":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/versioning-strategy.png" alt-text="Diagram showing the name-based versioning strategy for Durable Functions.":::
 
 In this strategy, every function must be copied, and its references to other functions must be updated. You can make it easier by writing a script. Here's a [sample project](https://github.com/TsuyoshiUshio/DurableVersioning) with a migration script.
 
@@ -75,7 +75,7 @@ Use the following procedure to set up this scenario.
 
 The following diagram shows the described configuration of deployment slots and storage accounts. In this potential predeployment scenario, version 2 of a function app is running in the production slot, while version 1 remains in the staging slot.
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-slot.png" alt-text="Deployment slots and storage accounts":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-slot.png" alt-text="Diagram showing deployment slots and storage accounts before slot swap.":::
 
 ### host.json examples
 
@@ -130,21 +130,21 @@ public static async Task<IActionResult> StatusCheck(
 
 Next, configure the staging gate to wait until no orchestrations are running. For more information, see [Release deployment control using gates](/azure/devops/pipelines/release/approvals/gates)
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-gate.png" alt-text="Deployment gate":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-gate.png" alt-text="Screenshot showing an Azure Pipelines deployment gate configuration.":::
 
 Azure Pipelines checks your function app for running orchestration instances before your deployment starts.
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-gate-2.png" alt-text="Deployment gate (running)":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-gate-2.png" alt-text="Screenshot showing a running Azure Pipelines deployment gate check.":::
 
 Now the new version of your function app should be deployed to the staging slot.
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-slot-2.png" alt-text="Staging slot":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-slot-2.png" alt-text="Diagram showing the new app version deployed to the staging slot.":::
 
 Finally, swap slots. 
 
 Application settings that aren't marked as deployment slot settings are also swapped, so the version 2 app keeps its reference to storage account A. Because orchestration state is tracked in the storage account, any orchestrations running on the version 2 app continue to run in the new slot without interruption.
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-slot-3.png" alt-text="Deployment slot":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/deployment-slot-3.png" alt-text="Diagram showing slot swap completion with app settings moved to production.":::
 
 To use the same storage account for both slots, you can change the names of your task hubs. In this case, you need to manage the state of your slots and your app's HubName settings. To learn more, see [Task hubs in Durable Functions](durable-functions-task-hubs.md).
 
@@ -166,17 +166,17 @@ The first time an orchestration request is received, the router does the followi
 
 The router manages the state of which version of your app's code is deployed to which function app in Azure.
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/application-routing.png" alt-text="Application routing (first time)":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/application-routing.png" alt-text="Diagram showing first-time application routing and deployment flow.":::
 
 The router directs deployment and orchestration requests to the appropriate function app based on the version sent with the request. It ignores the patch version.
 
 When you deploy a new version of your app without a breaking change, you can increment the patch version. The router deploys to your existing function app and sends requests for the old and new versions of the code, which are routed to the same function app.
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/application-routing-2.png" alt-text="Application routing (no breaking change)":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/application-routing-2.png" alt-text="Diagram showing application routing when there is no breaking change.":::
 
 When you deploy a new version of your app with a breaking change, you can increment the major or minor version. Then the application router creates a new function app in Azure, deploys to it, and routes requests for the new version of your app to it. In the following diagram, running orchestrations on the 1.0.1 version of the app keep running, but requests for the 1.1.0 version are routed to the new function app.
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/application-routing-3.png" alt-text="Application routing (breaking change)":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/application-routing-3.png" alt-text="Diagram showing application routing for a deployment with breaking changes.":::
 
 The router monitors the status of orchestrations on the 1.0.1 version and removes apps after all orchestrations are finished. 
 
@@ -186,7 +186,7 @@ Each function app should use separate scheduling queues, possibly in separate st
 
 For more information, see [Manage instances in Durable Functions in Azure](durable-functions-instance-management.md).
 
-:::image type="content" source="media/durable-functions-zero-downtime-deployment/tracking-store-settings.png" alt-text="Tracking store settings":::
+:::image type="content" source="media/durable-functions-zero-downtime-deployment/tracking-store-settings.png" alt-text="Diagram showing shared tracking store settings across versioned function apps.":::
 
 ## Next steps
 

articles/azure-functions/durable/durable-task-scheduler/durable-task-schedulers-schedules.md

@@ -211,7 +211,7 @@ Monitor scheduled orchestrations using the [Durable Task Scheduler dashboard](./
 
 Explore complete working examples that demonstrate schedule operations.
 
-- [Schedule console app](https://github.com/microsoft/durabletask-dotnet/tree/main/samples/ScheduleConsoleApp): A Demonstrates how to create, pause, resume, and list schedules in a console application.me, delete, and list endpoints.
+- [Schedule console app](https://github.com/microsoft/durabletask-dotnet/tree/main/samples/ScheduleConsoleApp): Demonstrates how to create, pause, resume, delete, and list schedules in a console application.
 
 ## Next steps
 

articles/azure-functions/durable/quickstart-js-vscode.md

@@ -262,7 +262,7 @@ Azure Functions Core Tools gives you the capability to run an Azure Functions pr
 
 4. In the terminal panel, copy the URL endpoint of your HTTP-triggered function.
 
-    :::image type="content" source="media/quickstart-js-vscode/functions-f5.png" alt-text="Screenshot of the Visual Studio code terminal panel. The terminal shows the output of running a Durable Functions app locally.":::
+    :::image type="content" source="media/quickstart-js-vscode/functions-f5.png" alt-text="Screenshot of the Visual Studio Code terminal panel. The terminal shows the output of running a Durable Functions app locally.":::
 
 ::: zone pivot="nodejs-model-v3"
 

articles/azure-functions/durable/quickstart-mssql.md

@@ -210,7 +210,7 @@ Open another terminal window in your app's root folder and start the Function ap
 
 ## Run your app in Azure
 
-To run your app in Azure, you need to create various resources. For convenient clean up later, create all the resources in the same resource group. 
+To run your app in Azure, you need to create various resources. For convenient cleanup later, create all the resources in the same resource group. 
 
 ### Create an Azure SQL database
 

articles/azure-functions/durable/quickstart-powershell-vscode.md

@@ -15,7 +15,7 @@ Use Durable Functions, a feature of [Azure Functions](../functions-overview.md),
 
 In this quickstart, you use the Durable Functions extension in Visual Studio Code to locally create and test a "hello world" Durable Functions app in Azure Functions. The Durable Functions app orchestrates and chains together calls to other functions. Then, you publish the function code to Azure. The tools you use are available via the Visual Studio Code extension.
 
-:::image type="content" source="./media/quickstart-js-vscode/functions-vs-code-complete.png" alt-text="Running a Durable Functions app in Azure.":::
+:::image type="content" source="./media/quickstart-js-vscode/functions-vs-code-complete.png" alt-text="Screenshot showing a Durable Functions app in Visual Studio Code.":::
 
 ## Prerequisites