Skip to content

Commit 1f8eafc

Browse files
committed
Remove tab formatting
1 parent dcea4b0 commit 1f8eafc

File tree

1 file changed

+0
-16
lines changed

1 file changed

+0
-16
lines changed

articles/azure-functions/durable/durable-functions-orchestration-versioning.md

Lines changed: 0 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -91,8 +91,6 @@ To implement version-aware logic in your orchestrator function, you can use the
9191
> [!IMPORTANT]
9292
> When implementing version-aware logic, it's **critically important** to preserve the exact orchestrator logic for older versions. Any changes to the sequence, order, or signature of activity calls for existing versions may break deterministic replay and cause in-flight orchestrations to fail or produce incorrect results. The old version code paths must remain unchanged once deployed.
9393
94-
# [C# (Isolated)](#tab/csharp-isolated)
95-
9694
```csharp
9795
[Function("MyOrchestrator")]
9896
public static async Task<string> RunOrchestrator(
@@ -112,8 +110,6 @@ public static async Task<string> RunOrchestrator(
112110
}
113111
```
114112

115-
---
116-
117113
> [!NOTE]
118114
> The `context.Version` property is **read-only** and reflects the version that was permanently associated with the orchestration instance when it was created. You cannot modify this value during orchestration execution. If you want to specify a version through means other than `host.json`, you can do so when starting an orchestration instance with the orchestration client APIs (see [Starting New Orchestrations with Specific Versions](#starting-new-orchestrations-with-specific-versions)).
119115
@@ -157,8 +153,6 @@ This example shows how to replace one activity with a different activity in the
157153

158154
**Orchestrator function:**
159155

160-
# [C# (Isolated)](#tab/csharp-isolated)
161-
162156
```csharp
163157
[Function("ProcessOrderOrchestrator")]
164158
public static async Task<string> ProcessOrder(
@@ -174,8 +168,6 @@ public static async Task<string> ProcessOrder(
174168
}
175169
```
176170

177-
---
178-
179171
#### Version 2.0 with discount processing
180172

181173
**host.json configuration:**
@@ -191,8 +183,6 @@ public static async Task<string> ProcessOrder(
191183

192184
**Orchestrator function:**
193185

194-
# [C# (Isolated)](#tab/csharp-isolated)
195-
196186
```csharp
197187
using DurableTask.Core.Settings;
198188

@@ -222,8 +212,6 @@ public static async Task<string> ProcessOrder(
222212
}
223213
```
224214

225-
---
226-
227215
## Advanced usage
228216

229217
For more sophisticated versioning scenarios, you can configure other settings to control how the runtime handles version matches and mismatches.
@@ -290,8 +278,6 @@ By default, all new orchestration instances are created with the current `defaul
290278

291279
You can override the default version by providing a specific version value when creating new orchestration instances using the orchestration client APIs. This allows fine-grained control over which version each new orchestration instance uses.
292280

293-
# [C# (Isolated)](#tab/csharp-isolated)
294-
295281
```csharp
296282
[Function("HttpStart")]
297283
public static async Task<HttpResponseData> HttpStart(
@@ -310,8 +296,6 @@ public static async Task<HttpResponseData> HttpStart(
310296
}
311297
```
312298

313-
---
314-
315299
### Removing legacy code paths
316300

317301
Over time, you may want to remove legacy code paths from your orchestrator functions to simplify maintenance and reduce technical debt. However, removing code must be done carefully to avoid breaking existing orchestration instances.

0 commit comments

Comments
 (0)