PR feedback

Author: cgillum

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

@@ -500,7 +500,7 @@ module.exports = df.entity(function(context) {
 ```
 
 > [!NOTE]
-> Durable Entities are available in JavaScript starting with version **1.3.0** of the `durable-functions` npm package.
+> Durable entities are available in JavaScript starting with version **1.3.0** of the `durable-functions` npm package.
 
 ## Entity client
 
@@ -633,7 +633,7 @@ module.exports = async function (context) {
 ```
 
 > [!NOTE]
-> Durable Entities are available in JavaScript starting with version **1.3.0** of the `durable-functions` npm package.
+> Durable entities are available in JavaScript starting with version **1.3.0** of the `durable-functions` npm package.
 
 <a name="host-json"></a>
 ## host.json settings

articles/azure-functions/durable/durable-functions-create-first-csharp.md

@@ -72,7 +72,7 @@ The following steps use a template to create the durable function code in your p
     ![Select durable template](./media/durable-functions-create-first-csharp/functions-vs-select-template.png)  
 
 > [!NOTE]
-> This template currently creates a Durable Function using an older 1.x version of the extension. See the [Durable Functions Versions](durable-functions-versions.md) article for information about how to upgrade to the newer 2.x versions of Durable Functions.
+> This template currently creates a durable function using an older 1.x version of the extension. See the [Durable Functions Versions](durable-functions-versions.md) article for information about how to upgrade to the newer 2.x versions of Durable Functions.
 
 A new durable function is added to the app.  Open the new .cs file to view the contents. This durable function is a simple function chaining example with the following methods:  
 

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

@@ -108,7 +108,7 @@ For more information on the class-based syntax and how to use it, see [Defining
 
 ### Example: JavaScript entity
 
-Durable Entities are available in JavaScript starting with version **1.3.0** of the `durable-functions` npm package. The following code is the *Counter* entity implemented as a durable function written in JavaScript.
+Durable entities are available in JavaScript starting with version **1.3.0** of the `durable-functions` npm package. The following code is the *Counter* entity implemented as a durable function written in JavaScript.
 
 **function.json**
 ```json
@@ -167,7 +167,6 @@ Below we show some examples that illustrate these various ways of accessing enti
 
 To access entities from an ordinary Azure Function - also known as *client function* - use the [entity client output binding](durable-functions-bindings.md#entity-client). The following example shows a queue-triggered function *signaling* an entity using this binding.
 
-**C#**
 ```csharp
 [FunctionName("AddFromQueue")]
 public static Task Run(
@@ -181,7 +180,6 @@ public static Task Run(
 }
 ```
 
-**JavaScript**
 ```javascript
 const df = require("durable-functions");
 
@@ -198,7 +196,6 @@ The term *signal* means that the entity API invocation is one-way and asynchrono
 
 Client functions can also query the state of an entity, as shown in the following example:
 
-**C#**
 ```csharp
 [FunctionName("QueryCounter")]
 public static async Task<HttpResponseMessage> Run(
@@ -211,7 +208,6 @@ public static async Task<HttpResponseMessage> Run(
 }
 ```
 
-**JavaScript**
 ```javascript
 const df = require("durable-functions");
 
@@ -228,7 +224,6 @@ Entity state queries are sent to the Durable tracking store and return the entit
 
 Orchestrator functions can access entities using APIs on the [orchestration trigger binding](durable-functions-bindings.md#orchestration-trigger). The following example code shows an orchestrator function *calling* and *signaling* a *Counter* entity.
 
-**C#**
 ```csharp
 [FunctionName("CounterOrchestration")]
 public static async Task Run(
@@ -246,7 +241,6 @@ public static async Task Run(
 }
 ```
 
-**JavaScript**
 ```javascript
 const df = require("durable-functions");
 
@@ -272,7 +266,6 @@ Only orchestrations are capable of calling entities and getting a response, whic
 An entity function can send signals to other entities (or even itself!) while it executes an operation.
 For example, we can modify the counter entity example above so it sends a "milestone-reached" signal to some monitor entity when the counter reaches the value 100:
 
-**C#**
 ```csharp
    case "add":
         var currentValue = ctx.GetState<int>();
@@ -286,7 +279,6 @@ For example, we can modify the counter entity example above so it sends a "miles
         break;
 ```
 
-**JavaScript**
 ```javascript
     case "add":
         const amount = context.df.getInput();

articles/azure-functions/durable/durable-functions-http-api.md

@@ -612,7 +612,7 @@ The responses for this API do not contain any content.
 Sends a one-way operation message to a [Durable Entity](durable-functions-types-features-overview.md#entity-functions). If the entity doesn't exist, it will be created automatically.
 
 > [!NOTE]
-> Durable Entities are available starting in Durable Functions 2.0.
+> Durable entities are available starting in Durable Functions 2.0.
 
 ### Request
 

articles/azure-functions/durable/durable-functions-instance-management.md

@@ -595,7 +595,6 @@ To remove all the data associated with an orchestration, you can purge the insta
 
 This method has two overloads. The first overload purges history by the ID of the orchestration instance:
 
-**C#**
 ```csharp
 [FunctionName("PurgeInstanceHistory")]
 public static Task Run(
@@ -606,7 +605,6 @@ public static Task Run(
 }
 ```
 
-**JavaScript**
 ```javascript
 const df = require("durable-functions");
 
@@ -618,7 +616,6 @@ module.exports = async function(context, instanceId) {
 
 The next example shows a timer-triggered function that purges the history for all orchestration instances that completed after the specified time interval. In this case, it removes data for all instances completed 30 or more days ago. It's scheduled to run once per day, at 12 AM:
 
-**C#**
 ```csharp
 [FunctionName("PurgeInstanceHistory")]
 public static Task Run(

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

@@ -214,7 +214,6 @@ Orchestrator functions aren't permitted to do I/O, as described in [orchestrator
 
 To simplify this common pattern, orchestrator functions can use the `CallHttpAsync` method in .NET to invoke HTTP APIs directly. In addition to supporting basic request/response patterns, `CallHttpAsync` supports automatic handling of common async HTTP 202 polling patterns, and also supports authentication with external services using [Managed Identities](../../active-directory/managed-identities-azure-resources/overview.md).
 
-**C#**
 ```csharp
 [FunctionName("CheckSiteAvailable")]
 public static async Task CheckSiteAvailable(
@@ -233,7 +232,6 @@ public static async Task CheckSiteAvailable(
 }
 ```
 
-**JavaScript**
 ```javascript
 const df = require("durable-functions");
 

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

@@ -329,7 +329,6 @@ To create the durable timer, call `context.CreateTimer` (.NET) or `context.df.cr
 
 An external client can deliver the event notification to a waiting orchestrator function by using either the [built-in HTTP APIs](durable-functions-http-api.md#raise-event) or by using the `RaiseEventAsync` (.NET) or `raiseEvent` (JavaScript) method from another function:
 
-**C#**
 ```csharp
 [FunctionName("RaiseEventToOrchestration")]
 public static async Task Run(
@@ -341,7 +340,6 @@ public static async Task Run(
 }
 ```
 
-**JavaScript**
 ```javascript
 const df = require("durable-functions");
 
@@ -352,7 +350,6 @@ module.exports = async function (context) {
 };
 ```
 
-**cURL**
 ```bash
 curl -d "true" http://localhost:7071/runtime/webhooks/durabletask/instances/{instanceId}/raiseEvent/ApprovalEvent -H "Content-Type: application/json"
 ```
@@ -367,7 +364,6 @@ The tricky thing about trying to implement this pattern with normal, stateless f
 
 You can use [Durable entities](durable-functions-entities.md) to easily implement this pattern as a single function.
 
-**C#**
 ```csharp
 [FunctionName("Counter")]
 public static void Counter([EntityTrigger] IDurableEntityContext ctx)
@@ -389,7 +385,6 @@ public static void Counter([EntityTrigger] IDurableEntityContext ctx)
 }
 ```
 
-**JavaScript**
 ```javascript
 const df = require("durable-functions");
 
@@ -410,7 +405,7 @@ module.exports = df.entity(function(context) {
 });
 ```
 
-Durable Entities can also be modeled as classes in .NET. This model can be useful if the list of operations is fixed and becomes large. The following example is an equivalent implementation of the `Counter` entity using .NET classes and methods.
+Durable entities can also be modeled as classes in .NET. This model can be useful if the list of operations is fixed and becomes large. The following example is an equivalent implementation of the `Counter` entity using .NET classes and methods.
 
 ```csharp
 public class Counter
@@ -432,7 +427,6 @@ public class Counter
 
 Clients can enqueue *operations* for (also known as "signaling") an entity function using the [entity client binding](durable-functions-bindings.md#entity-client).
 
-**C#**
 ```csharp
 [FunctionName("EventHubTriggerCSharp")]
 public static async Task Run(
@@ -452,7 +446,6 @@ public static async Task Run(
 > Dynamically generated proxies are also available in .NET for signaling entities in a type-safe way. And in addition to signaling, clients can also query for the state of an entity function using [type-safe methods](durable-functions-bindings.md#entity-client-usage) on the orchestration client binding.
 
 
-**JavaScript**
 ```javascript
 const df = require("durable-functions");
 

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

@@ -178,7 +178,7 @@ Activity, orchestrator, and entity function concurrency limits can be configured
 In the previous example, a maximum of 10 orchestrator or entity functions and 10 activity functions can run on a single VM concurrently. If not specified, the number of concurrent activity and orchestrator or entity function executions is capped at 10X the number of cores on the VM.
 
 > [!NOTE]
-> These settings are useful to help manage memory and CPU usage on a single VM. However, when scaled out across multiple VMs, each VM will have its own set of limits. These settings cannot be used to control concurrency at a global level.
+> These settings are useful to help manage memory and CPU usage on a single VM. However, when scaled out across multiple VMs, each VM has its own set of limits. These settings can't be used to control concurrency at a global level.
 
 ## Extended sessions
 
@@ -210,10 +210,10 @@ You can enable extended sessions by setting `durableTask/extendedSessionsEnabled
 
 There are two potential downsides of this setting to be aware of:
 
-1. There will be an overall increase in function app memory usage.
+1. There's an overall increase in function app memory usage.
 2. There can be an overall decrease in throughput if there are many concurrent, short-lived orchestrator or entity function executions.
 
-As an example, if `durableTask/extendedSessionIdleTimeoutInSeconds` is set to 30 seconds, then a short-lived orchestrator or entity function episode that executes in less than 1 second will still occupy memory for 30 seconds. It will also count against the `durableTask/maxConcurrentOrchestratorFunctions` quota mentioned previously, potentially preventing other orchestrator or entity functions from running.
+As an example, if `durableTask/extendedSessionIdleTimeoutInSeconds` is set to 30 seconds, then a short-lived orchestrator or entity function episode that executes in less than 1 second still occupies memory for 30 seconds. It also counts against the `durableTask/maxConcurrentOrchestratorFunctions` quota mentioned previously, potentially preventing other orchestrator or entity functions from running.
 
 The specific effects of extended sessions on orchestrator and entity functions are described in the next sections.
 
@@ -223,10 +223,10 @@ As mentioned previously, orchestrator functions are replayed using the contents
 
 The performance improvement of extended sessions is most often observed in the following situations:
 
-* When there are a limited number of orchestration instances running concurrently
-* When orchestrations have large number of sequential actions (e.g. hundreds of activity function calls) that complete quickly
-* When orchestrations fan-out and fan-in a large number of actions that complete around the same time
-* When orchestrator functions need to process large messages or do any CPU-intensive data processing
+* When there are a limited number of orchestration instances running concurrently.
+* When orchestrations have large number of sequential actions (e.g. hundreds of activity function calls) that complete quickly.
+* When orchestrations fan-out and fan-in a large number of actions that complete around the same time.
+* When orchestrator functions need to process large messages or do any CPU-intensive data processing.
 
 In all other situations, there is typically no observable performance improvement for orchestrator functions.
 
@@ -235,7 +235,7 @@ In all other situations, there is typically no observable performance improvemen
 
 ### Entity function unloading
 
-Entity functions will process up to 20 operations in a single batch. As soon as an entity finishes processing a batch of operations, it will persist its state and unload from memory. You can delay the unloading of entities from memory using the extended sessions setting. Entities will continue to persist their state changes as before, but will remain in memory for the configured period of time to reduce the number of loads from Azure Storage. This reduction of loads from Azure Storage can improve the overall throughput of frequently accessed entities.
+Entity functions process up to 20 operations in a single batch. As soon as an entity finishes processing a batch of operations, it persists its state and unloads from memory. You can delay the unloading of entities from memory using the extended sessions setting. Entities continue to persist their state changes as before, but remain in memory for the configured period of time to reduce the number of loads from Azure Storage. This reduction of loads from Azure Storage can improve the overall throughput of frequently accessed entities.
 
 ## Performance targets