# WorkflowNodeRetryPolicy
> Tracon documentation. Tracon is a .NET package family that adds a control
> plane on Microsoft Agent Framework, published as NuGet packages that run
> inside your own ASP.NET Core application.
>
> Page: https://tracon.dev/api/tracon.workflownoderetrypolicy/
> Summary: WorkflowNodeRetryPolicy: Retries a single workflow function node on a transient provider error instead of failing the whole run.
Namespace Tracon · Assembly Tracon.Workflows.dll
Retries a single workflow function node on a transient provider error
instead of failing the whole run.
```csharp
public sealed class WorkflowNodeRetryPolicy
```
- Inheritance
- object ← WorkflowNodeRetryPolicy
- Inherited Members
- object.GetType(), object.ToString(), object.Equals(object?), object.Equals(object?, object?), object.ReferenceEquals(object?, object?), object.GetHashCode()
## Remarks
Applies only to a node registered with
[TraconWorkflowFunctionExtensions.AddWorkflowFunction`](/api/tracon.traconworkflowfunctionextensions/).
Whether an error is transient is read from the registered
`IRunErrorClassifier` (the same taxonomy `runs.error_class`
uses) — a provider error, an open circuit breaker, a rate limit, or a
timeout is retried; every other class (a compilation failure, a blocked
tool, a budget being exceeded, cancellation, …) is not, since retrying
those cannot change the outcome.
A failure that carries a permanent HTTP status — any 4xx except 408
(request timeout) and 429 (rate limit) — is never retried, whatever its
class. A provider error can be a 4xx (for example a 401 or a 404), and the
same request gets the same answer again; a retried 409 on a
non-idempotent call can also repeat its side effect. The status is read
from `HttpRequestException.StatusCode` or from
an `HTTP nnn` text in the exception chain, and a registered
`IRunErrorClassifier` cannot override this rule.
The retry loop runs entirely INSIDE the node's own call — Microsoft
Agent Framework calls the node's handler once per routed message and
sees only its final outcome. A retried attempt is therefore invisible to
`TraconWorkflowOptions.MaxSuperSteps`: the node still counts as
exactly one super-step no matter how many attempts it took.
## Constructors
### WorkflowNodeRetryPolicy\(\)
```csharp
public WorkflowNodeRetryPolicy()
```
## Properties
### BackoffMultiplier
The multiplier applied to the delay after each further attempt.
```csharp
public double BackoffMultiplier { get; set; }
```
#### Property Value
[double](https://learn.microsoft.com/dotnet/api/system.double)
#### Remarks
Must be a finite, non-negative number; registration refuses any other value.
### InitialDelay
The delay before the second attempt.
```csharp
public TimeSpan InitialDelay { get; set; }
```
#### Property Value
[TimeSpan](https://learn.microsoft.com/dotnet/api/system.timespan)
#### Remarks
Must be from zero to about 49.7 days; registration refuses any other value. A
grown delay is capped at about 49.7 days.
### MaxAttempts
The most attempts a single call may take. One means no retry.
```csharp
public int MaxAttempts { get; set; }
```
#### Property Value
[int](https://learn.microsoft.com/dotnet/api/system.int32)