Merge pull request #297693 from MicrosoftDocs/main

Merged by Learn.Build PR Management system

Author: learn-build-service-prod[bot]

articles/azure-functions/durable/durable-functions-dotnet-isolated-overview.md

@@ -86,15 +86,20 @@ public class MyOrchestration : TaskOrchestrator<string, string>
 ```
 
 ## Durable entities
-Durable entities are supported in the .NET isolated worker. See [developer's guide](./durable-functions-dotnet-entities.md).
+
+Durable entities are supported in the .NET isolated worker. For more information, see the [developer's guide](./durable-functions-dotnet-entities.md).
 
 ## Migration guide
 
-This guide assumes you're starting with a .NET Durable Functions 2.x project.
+This process assumes you're starting with a .NET Durable Functions 2.x project running in-process with the Functions host. 
+
+### Migrate your project
+
+The first step is to [migrate your .NET project to the isolated worker process](../migrate-dotnet-to-isolated-model.md). 
 
-### Update your project
+### Update package reference 
 
-The first step is to update your project to [Azure Functions .NET isolated](../migrate-dotnet-to-isolated-model.md). Then, update your Durable Functions NuGet package references.
+After you've migrated your app to use the isolate worker process, you must update your Durable Functions NuGet package to reference the isolated worker-specific package, like in this example:
 
 Old:
 

articles/azure-functions/durable/durable-functions-overview.md

@@ -1108,6 +1108,8 @@ Most HTTP trigger templates require an access key in the request. So your HTTP r
 https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?code=<API_KEY>
 ```
 
+Function apps that run in containers use the domain of the container host. For an example HTTP endpoint hosted in Azure Container Apps, see the example in [this Container Apps hosting article](functions-deploy-container-apps.md#verify-your-functions-on-azure).
+
 The key can be included in a query string variable named `code`, as mentioned earlier. It can also be included in an `x-functions-key` HTTP header. The value of the key can be any function key defined for the function, or any host key.
 
 You can allow anonymous requests, which don't require keys. You can also require that the master key is used. You change the default authorization level by using the `authLevel` property in the binding JSON. 

articles/azure-functions/functions-bindings-http-webhook-trigger.md

@@ -41,7 +41,7 @@ Next, you create a function in the new function app.
 
 ## Create Azure Cosmos DB trigger
 
-1. In your function app, select **Overview**, and then select **+ Create** under **Functions**.
+1. In your function app, select **Overview** and then select **+ Create** under **Functions**. If you don't see a **Create** button, you must instead add your Azure Cosmos DB trigger to your local code project and then redeploy to Azure. For more information, see [Code and test Azure Functions locally](functions-develop-local.md).
 
 1. Under **Select a template**, scroll down and choose the **Azure Cosmos DB trigger** template.
 

articles/azure-functions/functions-create-cosmos-db-triggered-function.md

@@ -88,7 +88,7 @@ Next, create a function in the new function app.
 ::: zone pivot="programming-language-python,programming-language-javascript,programming-language-powershell,programming-language-csharp"  
 ## <a name="create-function"></a>Create an HTTP trigger function
 
-1. In your function app, select **Overview**, and then select **+ Create** under **Functions**. If you don't see the **+ Create** button, you can instead [create your functions locally](#create-your-functions-locally).
+1. In your function app, select **Overview**, and then select **+ Create** under **Functions**. If you don't see the **+ Create** button, you must instead [create your functions locally](./functions-develop-local.md).
 
 1. Under **Select a template**, scroll down and choose the **HTTP trigger** template.
 

articles/azure-functions/functions-create-function-app-portal.md

@@ -78,6 +78,9 @@ Each origin in your Azure Front Door origin group has a *Priority* property, whi
 
 ## <a name="weighted"></a>Weighted traffic-routing method
 
+> [!NOTE]
+> For customers with very low RPS (Requests Per Second), due to the nature of how distributed AFD POPs and machines are, we cannot guarantee that the weights configured by the customer will be strictly followed and the load balancing may appear skewed.
+
 The *Weighted* traffic-routing method allows you to distribute traffic based on predefined weights.
 
 In this method, you assign a weight to each origin in your Azure Front Door origin group. The weight is an integer between 1 and 1000, with a default value of **50**.

articles/azure-functions/functions-develop-vs.md

@@ -1,5 +1,5 @@
 ---
-title: Azure Front Door WebSocket (preview)
+title: Azure Front Door WebSocket
 description: This article describes how WebSocket work on Azure Front Door for real-time bidirectional communication between a server and client over a long running TCP connection.
 author: jessie-jyy
 ms.author: halkazwini