How to write retry logic in C#?

Retry logic in C# is a technique that automatically retries a failed operation several times before giving up or escalating the failure. It's commonly employed in scenarios where the failure is expected to be temporary or transient, such as network timeouts, database connection issues, or external service failures. Understanding the causes of failures, choosing appropriate retry strategies, and implementing error-handling procedures into effect are all essential to writing efficient retry logic.

Consider the following situation:

An API is being fetched for data by your application. Suddenly, the API is temporarily down because of a network issue. If you don't have retry logic, your application may crash immediately or enter an erroneous state. Instead, after some time, your application will attempt to retrieve the data again because of the implementation of retry logic. It may wait a little longer and attempt again if the API is still down, continuing this cycle until it succeeds or reaches its limit.

In C#, this retry logic may be achieved more effectively within a block of code by using error handling and loop statements, or it can be handled more effectively by using external libraries designed especially for this purpose. This approach is usually used for processes that contain transient errors or issues that may be resolved with more attempts.

Why Retry Logic?

Retry logic is a programming approach used in C# to manage temporary problems while an action is executed, especially when connecting with external resources or services like databases, web services, or APIs. Temporary issues, such as network problems, temporary server overloads, or other unanticipated factors, could result in transient errors. After some time, the process is usually retried to fix these problems.

Resilience: Retry logic increases the resilience of your program against temporary errors. If the failure was due to a transient problem, you can improve the chances of success by trying the procedure again.
Improvement of User Experience: Retry logic can enhance user experience by transparently handling temporary mistakes without requiring user participation. Service disruptions or unnecessary error messages may be avoided as a result.
Reduce External Dependencies: Many modern applications depend on external resources or services, such as databases, APIs, or cloud services. The use of retry logic can aid in reducing the impact of external dependencies that may not always be reliable.
Reducing Operational Overhead: Without retry logic, managing temporary errors sometimes requires complex error-handling code or user intervention. Retry logic simplifies this process by automating the retry attempts, reducing operational overhead and managing errors.
Optimizing Resource Usage: By distributing the retry attempts throughout time, retry logic may reduce the burden on temporary resource restrictions in situations where the failure occurred.

Delay Strategies for Retry Logic

Simple Retry: The simplest tactic is "simple retry", which is just attempting an operation a certain number of times if it fails.
Incremental Backoff: This method adds a delay between retries in a manner akin to exponential backoff. However, the increase in delay is linear as opposed to exponential. It might be useful if you still want some time to pass between retries but don't want to experience the occasionally long waits associated with exponential backoff.
Circuit Breaker: When many efforts fail, this advanced method "opens" a circuit breaker, which ends all further attempts for a specific period. By doing this, you may reduce number of times you try to overload a failing service.

A common design pattern in microservices architecture is the circuit breaker strategy, which prevents a network application from trying to do an activity that is likely to fail repeatedly.

Here is a brief overview of how it functions:

Closed state: At first, the circuit breaker is in its closed condition. Requests to a remote resource or service can proceed in this condition. The circuit breaker monitors for failure requests (specified error circumstances or exceptions).
Open State: The Circuit Breaker trips and enters an open condition when the number of failures exceeds a certain threshold in a specified period. In this state of the service, all requests are automatically blocked for a certain period of time (referred to as the "reset timeout"), and an error is returned immediately, removing the require for a network call. In addition to saving the application from being slowed down by repeatedly failed requests, it gives the failing service some time to recover.
Half-Open State: Upon the end of the reset timeout, the Circuit Breaker enters a half-open state. In this condition, it allows a certain number of test requests to get through. The Circuit Breaker returns to the closed state and assumes the service issue has been resolved if the above requests are successful. The Circuit Breaker returns to being open state and blocks requests for an additional timeout period if the test requests are failed.

An application's overall stability and usefulness can be enhanced by using the Circuit Breaker pattern, which can help make it more robust and keep it from being stuck when attempting an operation that is likely to fail.

When to Implement Retry Logic

Network Operations: Transient issues like timeouts or congestion might happen while sending out network requests, such as HTTP requests or database queries. Retry logic, which retries failed requests, may reduce these problems.
File Operations: Temporary problems like file locks or filesystem errors may arise while reading from or writing to files. When these errors occur, file operations can be retried using retry logic.
Database Operations: Timeouts, locking conflicts, or issues with the database server may temporarily cause database queries or transactions to fail. Database operations that fail can be tried again until they succeed by using retry logic.

Components of Retry Logic:

Retry logic is not just a single 'try again' command. It's a system made up of a number of interconnected components, each crucial in ensuring the logic works efficiently and effectively.

Here are the key components:

Retry policy: It is a set of rules that establishes when an operation should be retry. The maximum number of retry attempts and the conditions under which they should occur are often included. For example, we may decide to retry only on certain exceptions, like network-related ones, and avoid retrying on others, like those related to business logic.
Delay strategy: The period of time between retries is specified. An exponential backoff delay approach is a widely used technique in which the wait time doubles for each subsequent retry. It is advisable to avoid from overwhelming a system that is having struggles with retry attempts.
Exponential Backoff: An even more advanced delay method, exponential backoff, involves exponentially increasing the interval between attempts. The delay should be increased gradually, starting small and increasing with each consecutive retry attempt to provide the system more time to recover.

Common variations consist of:

Exponential Increase: Every time there is a retry attempt, the delay is doubled (i.e., 1 second, 2 seconds, 4 seconds, 8 seconds, and so on).
Randomized Exponential Backoff: This method of preventing synchronization problems involves adding a random factor to the delay, which results in small variations in the retry timings between various instances of the retrying system.

Example:

Let us take an example to illustrate the retry logic in C#.

using System;
using System.Threading;
class Demo
{
    static void Main(string[] args)
    {
        retryLogic(4, TimeSpan.FromSeconds(2), () =>
        {
            // Here, call your possibly failing method.
            // Let's simulate different error types for the sake of demonstration.
            Random r = new Random();
            int random_Number = r.Next(2, 7);
            if (random_Number == 2)
            {
                Console.WriteLine("Simulated successful.");
            }
            else if (random_Number >= 3 && random_Number <= 5)
            {
                Console.WriteLine("A Simulated transient error occurred.");
                throw new Exception("Simulated transient error");
            }
            else
            {
                Console.WriteLine("Simulated permanent error occurred.");
                throw new Exception("Simulated permanent error");
            }
        });
    }
    static void retryLogic(int retry_Count, TimeSpan delay, Action action)
    {
        for (int q = 0; q < retry_Count; q++)
        {
            try
            {
                action(); 
                // Execute the action
                return;  
                // If successful, return
            }
            catch (Exception e)
            {
                Console.WriteLine($"Attempt {q + 1} is failed: {e.Message}");
                if (q < retry_Count - 1 && IsTransientError(e))
                {
                    Console.WriteLine($"Retrying in just {delay.TotalSeconds} seconds...");
                    Thread.Sleep(delay);
                    // Before retrying, wait for the delay.
                }
                else
                {
                    Console.WriteLine("All attempts are failed.");
                    return;
                }
            }
        }
        Console.WriteLine("All attempts are failed.");
    }
    static bool IsTransientError(Exception e)
    {
        // Here, implement your logic to determine if the error is transitory.
        // In this example, we will consider any exception transient for simplicity.
        return true;
    }
}

Output:

A simulated transient error occurred.
Attempt 1 is failed: Simulated transient error
Retrying in just 2 seconds...
A simulated transient error occurred.
Attempt 2 is failed: Simulated transient error
Retrying in just 2 seconds...
A simulated transient error occurred.
Attempt 3 is failed: Simulated transient error
Retrying in just 2 seconds...
Simulated successful.

Next TopicInteresting Facts about C#

← prev next →