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: docs/features.md
+18-1Lines changed: 18 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -148,4 +148,21 @@ Orchestrations can be suspended using the `suspend_orchestration` client API and
148
148
149
149
### Retry policies
150
150
151
-
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.
151
+
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.
152
+
153
+
### Logging configuration
154
+
155
+
Both the TaskHubGrpcWorker and TaskHubGrpcClient (as well as DurableTaskSchedulerWorker and DurableTaskSchedulerClient for durabletask-azuremanaged) accept a log_handler and log_formatter objectfrom`logging`. These can be used to customize verbosity, output location, andformat of logs emitted by these sources.
156
+
157
+
For example, to output logs to a file called `worker.log` at level `DEBUG`, the following syntax might apply:
with DurableTaskSchedulerWorker(host_address=endpoint, secure_channel=secure_channel,
164
+
taskhub=taskhub_name, token_credential=credential, log_handler=log_handler) as w:
165
+
```
166
+
167
+
**NOTE**
168
+
The worker and client output many logs at the `DEBUG` level that will be useful when understanding orchestration flow and diagnosing issues with Durable applications. Before submitting issues, please attempt a repro of the issue with debug logging enabled.
0 commit comments