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: README.md
+226-3Lines changed: 226 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -118,15 +118,15 @@ Orchestrations can start child orchestrations using the `call_sub_orchestrator`
118
118
119
119
Orchestrations can wait for external events using the `wait_for_external_event` API. External events are useful for implementing human interaction patterns, such as waiting for a user to approve an order before continuing.
120
120
121
-
### Continue-as-new (TODO)
121
+
### Continue-as-new
122
122
123
123
Orchestrations can be continued as new using the `continue_as_new` API. This API allows an orchestration to restart itself from scratch, optionally with a new input.
124
124
125
125
### Suspend, resume, and terminate
126
126
127
127
Orchestrations can be suspended using the `suspend_orchestration` client API and will remain suspended until resumed using the `resume_orchestration` client API. A suspended orchestration will stop processing new events, but will continue to buffer any that happen to arrive until resumed, ensuring that no data is lost. An orchestration can also be terminated using the `terminate_orchestration` client API. Terminated orchestrations will stop processing new events and will discard any buffered events.
128
128
129
-
### Retry policies (TODO)
129
+
### Retry policies
130
130
131
131
Orchestrations can specify retry policies for activities and sub-orchestrations. These policies control how many times and how frequently an activity or sub-orchestration will be retried in the event of a transient error.
132
132
@@ -162,6 +162,9 @@ The following is more information about how to develop this project. Note that d
162
162
### Generating protobufs
163
163
164
164
```sh
165
+
# install dev dependencies for generating protobufs and running tests
To run the E2E tests on a specific python version (eg: 3.11), run the following command from the project root:
201
204
202
205
```sh
203
-
tox -e py311 -- e2e
206
+
tox -e py311-e2e
207
+
```
208
+
209
+
### Configuration
210
+
211
+
#### Connection Configuration
212
+
213
+
The SDK connects to a Durable Task sidecar. By default it uses `localhost:4001`. You can override via environment variables (checked in order):
214
+
215
+
-`DAPR_GRPC_ENDPOINT` - Full endpoint (e.g., `localhost:4001`, `grpcs://host:443`)
216
+
-`DAPR_GRPC_HOST` (or `DAPR_RUNTIME_HOST`) and `DAPR_GRPC_PORT` - Host and port separately
217
+
218
+
Example (common ports: 4001 for DurableTask-Go emulator, 50001 for Dapr sidecar):
219
+
220
+
```sh
221
+
export DAPR_GRPC_ENDPOINT=localhost:4001
222
+
# or
223
+
export DAPR_GRPC_HOST=localhost
224
+
export DAPR_GRPC_PORT=50001
225
+
```
226
+
227
+
228
+
#### Async Workflow Configuration
229
+
230
+
Configure async workflow behavior and debugging:
231
+
232
+
-`DAPR_WF_DISABLE_DETECTION` - Disable non-determinism detection (set to `true`)
233
+
234
+
Example:
235
+
236
+
```sh
237
+
export DAPR_WF_DISABLE_DETECTION=false
238
+
```
239
+
240
+
### Async workflow authoring
241
+
242
+
For a deeper tour of the async authoring surface (determinism helpers, sandbox modes, timeouts, concurrency patterns), see the Async Enhancements guide: [ASYNC_ENHANCEMENTS.md](./ASYNC_ENHANCEMENTS.md). The developer-facing migration notes are in [DEVELOPER_TRANSITION_GUIDE.md](./DEVELOPER_TRANSITION_GUIDE.md).
243
+
244
+
You can author orchestrators with `async def` using the new `durabletask.aio` package, which provides a comprehensive async workflow API:
Optional sandbox mode (`best_effort` or `strict`) patches `asyncio.sleep`, `random`, `uuid.uuid4`, and `time.time` within the workflow step to deterministic equivalents. This is best-effort and not a correctness guarantee.
261
+
262
+
In `strict` mode, `asyncio.create_task` is blocked inside workflows to preserve determinism and will raise a `SandboxViolationError` if used.
263
+
264
+
> **Enhanced Sandbox Features**: The enhanced version includes comprehensive non-determinism detection, timeout support, enhanced concurrency primitives, and debugging tools. See [ASYNC_ENHANCEMENTS.md](./durabletask/aio/ASYNCIO_ENHANCEMENTS.md) for complete documentation.
265
+
266
+
#### Async patterns
267
+
268
+
- Activities and sub-orchestrations can be referenced by function object or by their registered string name. Both forms are supported:
269
+
- Function reference (preferred for IDE/type support) or string name (useful across modules/languages).
270
+
271
+
- Activities:
272
+
```python
273
+
result =await ctx.call_activity("process", input={"x": 1})
274
+
# or: result = await ctx.call_activity(process, input={"x": 1})
204
275
```
205
276
277
+
- Timers:
278
+
```python
279
+
await ctx.sleep(1.5) # seconds or timedelta
280
+
```
281
+
282
+
- External events:
283
+
```python
284
+
val =await ctx.wait_for_external_event("approval")
- Async authoring (`durabletask.aio`): awaiting returns the operation's value. Exceptions are raised on `await` (no `is_failed`).
302
+
- Generator authoring (`durabletask.task`): yielding returns `Task` objects. Use `get_result()` to read values; failures surface via `is_failed()` or by raising on `get_result()`.
303
+
304
+
Examples:
305
+
306
+
```python
307
+
# Async authoring (await returns value)
308
+
# when_any returns a proxy that compares equal to the original awaitable
309
+
# and exposes get_result() for the completed item.
- Useful for routing, observability, and cross-cutting concerns passed along activity/sub-orchestrator calls via the sidecar.
373
+
- In python-sdk, available for both async and generator orchestrators. In this repo, currently implemented on `durabletask.aio`; generator parity is planned.
374
+
375
+
- Cross-app activity/sub-orchestrator routing (async only for now):
376
+
```python
377
+
# Route activity to a different app via app_id
378
+
result =await ctx.call_activity("process", input=data, app_id="worker-app-2")
- The `app_id` parameter enables multi-app orchestrations where activities or child workflows run in different application instances.
385
+
- Requires sidecar support for cross-app invocation.
386
+
387
+
#### Worker readiness
388
+
389
+
When starting a worker and scheduling immediately, wait for the connection to the sidecar to be established:
390
+
391
+
```python
392
+
with TaskHubGrpcWorker() as worker:
393
+
worker.add_orchestrator(my_orch)
394
+
worker.start()
395
+
worker.wait_for_ready(timeout=5)
396
+
# Now safe to schedule
397
+
```
398
+
399
+
#### Suspension & termination
400
+
401
+
-`ctx.is_suspended` reflects suspension state during replay/processing.
402
+
- Suspend pauses progress without raising inside async orchestrators.
403
+
- Terminate completes with `TERMINATED` status; use client APIs to terminate/resume.
404
+
- Only new events are buffered while suspended; replay events continue to apply to rebuild local state deterministically.
405
+
406
+
### Tracing and context propagation
407
+
408
+
The SDK surfaces W3C tracing context provided by the sidecar:
409
+
410
+
- Orchestrations: `ctx.trace_parent`, `ctx.trace_state`, and `ctx.orchestration_span_id` are available on `OrchestrationContext` (and on `AsyncWorkflowContext`).
411
+
- Activities: `ctx.trace_parent` and `ctx.trace_state` are available on `ActivityContext`.
412
+
413
+
Propagate tracing to external systems (e.g., HTTP):
- The sidecar controls inbound `traceparent`/`tracestate`. App code can append vendor entries to `tracestate` for outbound calls but cannot currently alter the sidecar’s propagation for downstream Durable operations.
427
+
- Configure the sidecar endpoint with `DURABLETASK_GRPC_ENDPOINT` (e.g., `127.0.0.1:56178`).
428
+
206
429
## Contributing
207
430
208
431
This project welcomes contributions and suggestions. Most contributions require you to agree to a
0 commit comments