You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-functions/durable/durable-functions-orchestration-versioning.md
-16Lines changed: 0 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -91,8 +91,6 @@ To implement version-aware logic in your orchestrator function, you can use the
91
91
> [!IMPORTANT]
92
92
> 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.
93
93
94
-
# [C# (Isolated)](#tab/csharp-isolated)
95
-
96
94
```csharp
97
95
[Function("MyOrchestrator")]
98
96
publicstaticasyncTask<string>RunOrchestrator(
@@ -112,8 +110,6 @@ public static async Task<string> RunOrchestrator(
112
110
}
113
111
```
114
112
115
-
---
116
-
117
113
> [!NOTE]
118
114
> 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)).
119
115
@@ -157,8 +153,6 @@ This example shows how to replace one activity with a different activity in the
157
153
158
154
**Orchestrator function:**
159
155
160
-
# [C# (Isolated)](#tab/csharp-isolated)
161
-
162
156
```csharp
163
157
[Function("ProcessOrderOrchestrator")]
164
158
publicstaticasyncTask<string>ProcessOrder(
@@ -174,8 +168,6 @@ public static async Task<string> ProcessOrder(
174
168
}
175
169
```
176
170
177
-
---
178
-
179
171
#### Version 2.0 with discount processing
180
172
181
173
**host.json configuration:**
@@ -191,8 +183,6 @@ public static async Task<string> ProcessOrder(
191
183
192
184
**Orchestrator function:**
193
185
194
-
# [C# (Isolated)](#tab/csharp-isolated)
195
-
196
186
```csharp
197
187
usingDurableTask.Core.Settings;
198
188
@@ -222,8 +212,6 @@ public static async Task<string> ProcessOrder(
222
212
}
223
213
```
224
214
225
-
---
226
-
227
215
## Advanced usage
228
216
229
217
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
290
278
291
279
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.
292
280
293
-
# [C# (Isolated)](#tab/csharp-isolated)
294
-
295
281
```csharp
296
282
[Function("HttpStart")]
297
283
publicstaticasyncTask<HttpResponseData>HttpStart(
@@ -310,8 +296,6 @@ public static async Task<HttpResponseData> HttpStart(
310
296
}
311
297
```
312
298
313
-
---
314
-
315
299
### Removing legacy code paths
316
300
317
301
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