| name | http-pipeline |
| description | Use when changing HTTP handlers, retry behavior, or pipeline ordering in Contentstack.Management.Core.Runtime.Pipeline. |
HTTP pipeline and retries – Contentstack Management .NET SDK
When to use
Instructions
Pipeline construction and handler order
ContentstackClient.BuildPipeline registers handlers in this outer-to-inner order for execution:
HttpHandler — sends the HttpRequestMessage via the SDK’s HttpClient.
RetryHandler — wraps the inner handler and applies RetryPolicy.
Incoming calls traverse RetryHandler first, which delegates to HttpHandler for the actual HTTP call, then inspects success/failure and may retry.
Policy selection
- If
ContentstackClientOptions.RetryPolicy is set, that instance is used.
- Otherwise
RetryConfiguration.FromOptions(contentstackOptions) builds a RetryConfiguration, then new DefaultRetryPolicy(retryConfiguration).
Retry configuration
RetryConfiguration holds defaults and toggles, including:
RetryOnError, RetryLimit, RetryDelay
- Network vs HTTP retries:
RetryOnNetworkFailure, RetryOnDnsFailure, RetryOnSocketFailure, MaxNetworkRetries, NetworkRetryDelay, RetryOnHttpServerError, etc.
Exact defaults and edge cases belong in code comments and unit tests—do not duplicate the full matrix here; change the source and tests together.
HTTP status codes (default policy)
DefaultRetryPolicy maintains a set of status codes that may trigger HTTP retries (e.g. selected 5xx, 429, timeouts, Unauthorized in the default set). When adjusting this list, consider:
- Risk of retrying non-idempotent operations.
- Interaction with auth refresh / OAuth flows on
ContentstackClient.
Tests