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/functions-bindings-error-pages.md
+58-49Lines changed: 58 additions & 49 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,73 +1,78 @@
1
1
---
2
2
title: Azure Functions error handling and retry guidance
3
-
description: Learn to handle errors and retry events in Azure Functions with links to specific binding errors, including information on retry policies.
4
-
3
+
description: Learn how to handle errors and retry events in Azure Functions, with links to specific binding errors, including information on retry policies.
Handling errors in Azure Functions is important to avoid lost data, missed events, and to monitor the health of your application. It's also important to understand the retry behaviors of event-based triggers.
11
+
Handling errors in Azure Functions is important to help you avoid lost data, avoid missed events, and monitor the health of your application. It's also an important way to help you understand the retry behaviors of event-based triggers.
13
12
14
13
This article describes general strategies for error handling and the available retry strategies.
15
14
16
15
> [!IMPORTANT]
17
-
> The retry policy support in the runtime for triggers other than Timer, Kafka, and Event Hubs is being removed after this feature becomes generally available (GA). Preview retry policy support for all triggers other than Timer and Event Hubs will be removed in December 2022. For more information, see the [Retries section below](#retries).
16
+
> We're removing retry policy support in the runtime for triggers other than Timer, Kafka, and Event Hubs after this feature becomes generally available (GA). Preview retry policy support for all triggers other than Timer and Event Hubs was removed in December 2022. For more information, see the [Retries](#retries) section.
18
17
19
18
## Handling errors
20
19
21
-
Errors raised in an Azure Functions can come from any of the following origins:
20
+
Errors that occur in an Azure function can result from any of the following:
22
21
23
-
- Use of built-in Azure Functions [triggers and bindings](functions-triggers-bindings.md).
24
-
- Calls to APIs of underlying Azure services.
25
-
- Calls to REST endpoints.
26
-
- Calls to client libraries, packages, or third-party APIs.
22
+
- Use of built-in Azure Functions [triggers and bindings](functions-triggers-bindings.md)
23
+
- Calls to APIs of underlying Azure services
24
+
- Calls to REST endpoints
25
+
- Calls to client libraries, packages, or third-party APIs
27
26
28
-
Good error handling practices are important to avoid loss of data or missed messages. This section describes some recommended errorhandling practices with links to more information.
27
+
To avoid loss of data or missed messages, it's important to practice good error handling. This section describes some recommended error-handling practices and provides links to more information.
29
28
30
29
### Enable Application Insights
31
30
32
-
Azure Functions integrates with Application Insights to collect error data, performance data, and runtime logs. You should use Application Insights to discover and better understand errors occurring in your function executions. To learn more, see [Monitor Azure Functions](functions-monitoring.md).
31
+
Azure Functions integrates with Application Insights to collect error data, performance data, and runtime logs. You should use Application Insights to discover and better understand errors that occur in your function executions. To learn more, see [Monitor Azure Functions](functions-monitoring.md).
33
32
34
33
### Use structured error handling
35
34
36
35
Capturing and logging errors is critical to monitoring the health of your application. The top-most level of any function code should include a try/catch block. In the catch block, you can capture and log errors. For information about what errors might be raised by bindings, see [Binding error codes](#binding-error-codes).
37
36
38
37
### Plan your retry strategy
39
38
40
-
Several Functions bindings extensions provide built-in support for retries. In addition, the runtime lets you define retry policies for Timer, Kafka, and Event Hubstriggered functions. To learn more, see [Retries](#retries). For triggers that don't provide retry behaviors, you may want to implement your own retry scheme.
39
+
Several Functions bindings extensions provide built-in support for retries. In addition, the runtime lets you define retry policies for Timer, Kafka, and Event Hubs-triggered functions. To learn more, see [Retries](#retries). For triggers that don't provide retry behaviors, you might want to implement your own retry scheme.
41
40
42
41
### Design for idempotency
43
42
44
-
The occurrence of errors when processing data can be a problem for your functions, especially when processing messages. You need to consider what happens when the error occurs and how to avoid duplicate processing. To learn more, see [Designing Azure Functions for identical input](functions-idempotent.md).
43
+
The occurrence of errors when you're processing data can be a problem for your functions, especially when you're processing messages. It's important to consider what happens when the error occurs and how to avoid duplicate processing. To learn more, see [Designing Azure Functions for identical input](functions-idempotent.md).
45
44
46
45
## Retries
47
46
48
-
There are two kinds of retries available for your functions: built-in retry behaviors of individual trigger extensions and retry policies. The following table indicates which triggers support retries and where the retry behavior is configured. It also links to more information about errors coming from the underlying services.
47
+
There are two kinds of retries available for your functions:
48
+
* Built-in retry behaviors of individual trigger extensions
49
+
* Retry policies provided by the Functions runtime
50
+
51
+
The following table indicates which triggers support retries and where the retry behavior is configured. It also links to more information about errors that come from the underlying services.
| RabbitMQ |[Binding extension](functions-bindings-rabbitmq-trigger.md#dead-letter-queues)|[Dead letter queue](https://www.rabbitmq.com/dlx.html)|
58
-
| Service Bus |[Binding extension](../service-bus-messaging/service-bus-dead-letter-queues.md)|[Dead letter queue](../service-bus-messaging/service-bus-dead-letter-queues.md#maximum-delivery-count)|
61
+
|Azure Service Bus |[Binding extension](../service-bus-messaging/service-bus-dead-letter-queues.md)|[Dead letter queue](../service-bus-messaging/service-bus-dead-letter-queues.md#maximum-delivery-count)|
Starting with version 3.x of the Azure Functions runtime, you can define a retry policies for Timer, Kafka, and Event Hubs triggers that are enforced by the Functions runtime. The retry policy tells the runtime to rerun a failed execution until either successful completion occurs or the maximum number of retries is reached.
67
+
Starting with version 3.x of the Azure Functions runtime, you can define retry policies for Timer, Kafka, and Event Hubs triggers that are enforced by the Functions runtime.
68
+
69
+
The retry policy tells the runtime to rerun a failed execution until either successful completion occurs or the maximum number of retries is reached.
65
70
66
-
A retry policy is evaluated when a Timer, Kafka, or Event Hubstriggered function raises an uncaught exception. As a best practice, you should catch all exceptions in your code and rethrow any errors that you want to result in a retry. Event Hubs checkpoints won't be written until the retry policy for the execution has completed. Because of this behavior, progress on the specific partition is paused until the current batch has completed.
71
+
A retry policy is evaluated when a Timer, Kafka, or Event Hubs-triggered function raises an uncaught exception. As a best practice, you should catch all exceptions in your code and rethrow any errors that you want to result in a retry. Event Hubs checkpoints won't be written until the retry policy for the execution has finished. Because of this behavior, progress on the specific partition is paused until the current batch has finished.
67
72
68
73
#### Retry strategies
69
74
70
-
There are two retry strategies supported by policy that you can configure:
75
+
You can configure two retry strategies that are supported by policy:
71
76
72
77
# [Fixed delay](#tab/fixed-delay)
73
78
@@ -81,7 +86,11 @@ The first retry waits for the minimum delay. On subsequent retries, time is adde
81
86
82
87
#### Max retry counts
83
88
84
-
You can configure the maximum number of times function execution is retried before eventual failure. The current retry count is stored in memory of the instance. It's possible that an instance has a failure between retry attempts. When an instance fails during a retry policy, the retry count is lost. When there are instance failures, the Event Hubs trigger is able to resume processing and retry the batch on a new instance, with the retry count reset to zero. Timer trigger doesn't resume on a new instance. This behavior means that the max retry count is a best effort, and in some rare cases an execution could be retried more than the maximum. For Timer triggers, the retries can be less than the maximum requested.
89
+
You can configure the maximum number of times that a function execution is retried before eventual failure. The current retry count is stored in memory of the instance.
90
+
91
+
It's possible for an instance to have a failure between retry attempts. When an instance fails during a retry policy, the retry count is lost. When there are instance failures, the Event Hubs trigger is able to resume processing and retry the batch on a new instance, with the retry count reset to zero. The timer trigger doesn't resume on a new instance.
92
+
93
+
This behavior means that the maximum retry count is a best effort. In some rare cases, an execution could be retried more than the requested maximum number of times. For Timer triggers, the retries can be less than the maximum number requested.
Here's the retry policy in the *function.json* file:
164
173
@@ -179,12 +188,12 @@ Here's the retry policy in the *function.json* file:
179
188
}
180
189
```
181
190
182
-
|function.jsonproperty | Description |
191
+
|*function.json* property | Description |
183
192
|---------|-------------|
184
193
|strategy|Use `exponentialBackoff`.|
185
194
|maxRetryCount|Required. The maximum number of retries allowed per function execution. `-1` means to retry indefinitely.|
186
-
|minimumInterval|The minimum retry delay. Specify as a string with the format `HH:mm:ss`.|
187
-
|maximumInterval|The maximum retry delay. Specify as a string with the format `HH:mm:ss`.|
195
+
|minimumInterval|The minimum retry delay. Specify it as a string with the format `HH:mm:ss`.|
196
+
|maximumInterval|The maximum retry delay. Specify it as a string with the format `HH:mm:ss`.|
188
197
189
198
---
190
199
::: zone-end
@@ -231,18 +240,18 @@ Here's the retry policy in the *function.json* file:
231
240
232
241
---
233
242
234
-
|function.json property | Description |
243
+
|*function.json* property | Description |
235
244
|---------|-------------|
236
245
|strategy|Required. The retry strategy to use. Valid values are `fixedDelay` or `exponentialBackoff`.|
237
246
|maxRetryCount|Required. The maximum number of retries allowed per function execution. `-1` means to retry indefinitely.|
238
-
|delayInterval|The delay that is used between retries when using a `fixedDelay` strategy. Specify as a string with the format `HH:mm:ss`.|
239
-
|minimumInterval|The minimum retry delay when using an `exponentialBackoff` strategy. Specify as a string with the format `HH:mm:ss`.|
240
-
|maximumInterval|The maximum retry delay when using `exponentialBackoff` strategy. Specify as a string with the format `HH:mm:ss`.|
247
+
|delayInterval|The delay that's used between retries when you're using a `fixedDelay` strategy. Specify it as a string with the format `HH:mm:ss`.|
248
+
|minimumInterval|The minimum retry delay when you're using an `exponentialBackoff` strategy. Specify it as a string with the format `HH:mm:ss`.|
249
+
|maximumInterval|The maximum retry delay when you're using `exponentialBackoff` strategy. Specify it as a string with the format `HH:mm:ss`.|
241
250
242
251
::: zone-end
243
252
::: zone pivot="programming-language-python"
244
253
245
-
Here's a Python sample to use retry context in a function:
254
+
Here's a Python sample that uses the retry context in a function:
246
255
247
256
```Python
248
257
import azure.functions
@@ -291,29 +300,29 @@ public void run(
291
300
|Element | Description |
292
301
|---------|-------------|
293
302
|maxRetryCount|Required. The maximum number of retries allowed per function execution. `-1` means to retry indefinitely.|
294
-
|delayInterval|The delay that is used between retries when using a `fixedDelay` strategy. Specify as a string with the format `HH:mm:ss`.|
295
-
|minimumInterval|The minimum retry delay when using an `exponentialBackoff` strategy. Specify as a string with the format `HH:mm:ss`.|
296
-
|maximumInterval|The maximum retry delay when using `exponentialBackoff` strategy. Specify as a string with the format `HH:mm:ss`.|
303
+
|delayInterval|The delay that's used between retries when you're using a `fixedDelay` strategy. Specify it as a string with the format `HH:mm:ss`.|
304
+
|minimumInterval|The minimum retry delay when you're using an `exponentialBackoff` strategy. Specify it as a string with the format `HH:mm:ss`.|
305
+
|maximumInterval|The maximum retry delay when you're using `exponentialBackoff` strategy. Specify it as a string with the format `HH:mm:ss`.|
297
306
298
307
---
299
308
300
309
::: zone-end
301
310
302
311
## Binding error codes
303
312
304
-
When integrating with Azure services, errors may originate from the APIs of the underlying services. Information relating to binding-specific errors is available in the **Exceptions and return codes** section of the following articles:
313
+
When you're integrating with Azure services, errors might originate from the APIs of the underlying services. Information that relates to binding-specific errors is available in the "Exceptions and return codes" sections of the following articles:
0 commit comments