-
Notifications
You must be signed in to change notification settings - Fork 16
Retry Policies
Workflow actions that communicate with external dependencies can be configured for automatic retry in the case of failure. Although automatic reties are desirable in a production workflow, they are less useful in a unit test which is focussing on testing the workflow functionality and needs to complete relatively quickly. For example, a workflow with a HTTP action configured to retry 4 times with an exponential back-off is going to take a while to run when testing a scenario where the called service returns a HTTP 500 response.
The testing framework will automatically modify a workflow to remove any retry policies and replace with a retry policy of type none. This ensures that failure scenarios can be tested without automatic retries and long test durations.
As an example, this HTTP action includes an exponential retry policy that retries 4 times:
"Get_Record": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "http://something.com/api/v1",
"retryPolicy": {
"type": "exponential",
"count": 4,
"interval": "PT7S",
"minimumInterval": "PT5S",
"maximumInterval": "PT30S"
}
}
}The testing framework will replace the existing retry policy with a new policy of type none:
"Get_Record": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "http://something.com/api/v1",
"retryPolicy": {
"type": "none"
}
}
}The test execution log will include logging to show what actions have been updated:
Updating workflow HTTP actions to remove any existing Retry policies and replace with a 'none' policy:
Get_Record
- Home
- Using the Testing Framework
- Test Configuration
- Azurite
- Local Settings File
- Test Execution Logs
- Stateless Workflows
- Handling Workflow Dependencies
- Fluent API
- Automated testing using a DevOps pipeline
- Summary of Test Configuration Options
-
Example Mock Requests and Responses
- Call a Local Function action
- Invoke Workflow action
- Built-In Connectors:
- Service Bus
- SMTP
- Storage Account
- SQL Server