Retry
A retry is a subsequent attempt to perform an operation after an earlier attempt fails or does not complete successfully.
AI Agents in Action, Second Edition
A retry is a repeated attempt to perform an API operation after an earlier attempt fails or does not complete successfully.
- How it is used
- Recovers agent flows and task loops from rejected outputs or transient tool failures without leaving attempts unbounded.
- How deep it goes
- Works through a three-attempt guardrail loop and task-loop exercises, while deferring backoff to a production recommendation.
- Examples
- Uses a guarded research-plan handoff, a failing text-transformation tool, and a critic that retries an answer against a test tool.
- What you can do after
- Build it from scratch as a bounded retry loop that feeds back failures and reports exhausted attempts.
Read how AI Agents in Action, Second Edition explains retry →
The Art of Code
Retry is a failure-recovery technique that repeats an unsuccessful operation in the hope that a transient problem has cleared.
- How it is used
- Recovers from transient technical failures in remote operations before selecting fallback or clear failure handling.
- How deep it goes
- Explains when to retry, limits attempts, and pairs repeated failure with circuit breaking and fallback.
- Examples
- Uses an external-system timeout caused by temporary network trouble or brief application unavailability.
- What you can do after
- Evaluate/understand when a technical failure merits bounded retry rather than fallback or immediate failure.
API Design Patterns
A retry is a subsequent attempt to perform an operation after an earlier attempt fails.
- How it is used
- Guides clients in deciding whether, when, and how often to repeat failed API requests.
- How deep it goes
- Explains failure classification, deduplication, exponential back-off, jitter, limits, and server-directed timing through an API implementation.
- Examples
- Uses failed exports, ambiguous API responses, HTTP 429 and 403 errors, and a GetChatRoom implementation.
- What you can do after
- Apply retry policies with failure classification, bounded exponential back-off, jitter, deduplication, and Retry-After handling.
Amazon Web Services in Action, Third Edition: An in-depth guide to AWS
A retry is a repeated attempt to perform an operation after an earlier attempt failed or its result is uncertain.
- How it is used
- Uses retries to recover from temporary failures in fault-tolerant requests, queued work, and concurrent updates.
- How deep it goes
- Explains who retries, when queued messages reappear, how idempotence prevents duplicates, and when failed attempts need investigation.
- Examples
- Illustrates duplicate blog posts, database-version conflicts, and messages repeatedly returning to an SQS queue.
- What you can do after
- Operate/configure it by making repeated operations idempotent and routing persistently failing SQS messages to a monitored dead-letter queue.
Read how Amazon Web Services in Action, Third Edition: An in-depth guide to AWS explains retry →
Effective Conversational AI
A retry is a conversational handling path that asks the user to provide input again after an attempted response is not accepted.
- How it is used
- Guides users back into a conversational flow after incomplete, invalid, misunderstood, or unrecognized input.
- How deep it goes
- Explains triggers, wording, thresholds, alternatives, and escalation, without specifying implementation code.
- Examples
- Uses voice prompts, message-or-call choices, alternate phone numbers, account lookups, and thirteen-digit claim numbers.
- What you can do after
- Diagnose/debug with it by distinguishing recoverable input errors from backend failures, then choosing guidance, an alternate path, or escalation.
gRPC Microservices in Go
Retry is the repeated execution of a failed operation according to specified conditions or limits.
- How it is used
- Uses retry on the consumer side to recover gRPC communication with a temporarily failing dependent service.
- How deep it goes
- Explains retry selection, idempotency, waiting limits and circuit-breaker trade-offs, but does not supply a complete retry-policy implementation.
- Examples
- Illustrates retry decisions with a lost user-deletion response, an Order-to-Shipping dependency failure and gRPC error statuses.
- What you can do after
- Apply it via a gRPC client policy that retries eligible failures while bounding waits and avoiding invalid-request retries.
Build AI-Enhanced Web Apps
Retrying failed requests is a technique that resubmits a request after a temporary failure, subject to a configured attempt limit.
- How it is used
- Handles temporary failures during AI API requests before returning an ultimate failure.
- How deep it goes
- Defines retryable conditions and attempt limits, but does not detail backoff algorithms or comprehensive error-handling workflows.
- Examples
- Uses streamText with maxRetries set to three and identifies HTTP 429 responses as retryable.
- What you can do after
- Apply retries via maxRetries on AI SDK request functions for transient failures.
ASP.NET Core in Action, 3e
A retry policy is a resilience rule that repeats a failed operation according to configured retry conditions and limits.
- How it is used
- Protects remote HTTP calls from transient network, server, and timeout failures through IHttpClientFactory pipelines.
- How deep it goes
- Defines setup steps, default failure conditions, delayed retry behavior, limits, and safe-request cautions without detailing advanced strategies.
- Examples
- Uses an ExchangeRatesClient with three waits of 200 milliseconds, 500 milliseconds, and one second.
- What you can do after
- Configure transient HTTP retries for named or typed clients using Microsoft.Extensions.Http.Polly and Polly policies.
.NET in Action, Second Edition
A retry policy is a resilience rule that automatically repeats an operation after qualifying failures.
- How it is used
- Deploys retries to isolate transient database and HTTP failures in production applications.
- How deep it goes
- Explains transient classification, exponential back-off, transaction uncertainty, and policy registration, but does not fully develop Polly’s broader strategies.
- Examples
- Uses EF Core money transfers, SQL Server configuration, mocked XKCD HTTP responses, Polly handlers, and exponential delays.
- What you can do after
- Apply it via EF Core execution strategies and Polly policies, including transaction verification and tested HTTP back-off.
Kafka for Architects
A retry is a configured or performed subsequent attempt to complete an operation after a transient failure.
- How it is used
- Configures Kafka producers to recover from transient send failures and missing acknowledgments.
- How deep it goes
- Explains retry counts, delivery and request timeouts, duplicate risk, reordering, and idempotent sequencing without implementation walkthroughs.
- Examples
- Uses lost acknowledgments and batches 1 and 2 to show duplicate and out-of-order delivery risks.
- What you can do after
- Configure Kafka producer retries with timeout boundaries and idempotence safeguards for duplicate-free, ordered partition writes.
Knowledge Graphs and LLMs in Action
A retry mechanism is a control procedure that repeats a failed operation according to configured retry conditions.
- How it is used
- Uses bounded retries to recover failed graph queries within a stateful QA pipeline.
- How deep it goes
- Implements error capture, counter updates, conditional routing, and termination after three runs.
- Examples
- Demonstrates recovery from Neo4j ClientError exceptions during generated Cypher query execution.
- What you can do after
- Build it from scratch by storing retry state and adding bounded conditional edges to a LangGraph pipeline.
Read how Knowledge Graphs and LLMs in Action explains retry →
Logs and Telemetry
A retry is a repeated attempt to perform an operation after an earlier attempt fails or its destination is unavailable.
- How it is used
- Protects event output and application flows from transient network failures and unavailable destinations.
- How deep it goes
- Explains result states, randomized exponential delays, scheduler bounds, and retry limits, stopping short of plugin implementation details.
- Examples
- Uses Fluent Bit HTTP-forward configuration and an unavailable destination that produces repeated attempts before failure.
- What you can do after
- Operate/configure Fluent Bit retries with scheduler bounds and a finite retry limit, and distinguish manageable errors from intervention-worthy rates.
Apache Kafka in Action
A retry is a technique or mechanism that repeats an operation after a failure or timeout in an attempt to complete it successfully.
- How it is used
- Configures recovery from transient Kafka producer failures and external-system outages in Kafka Connect.
- How deep it goes
- Explains retry timing, total deadlines, connector-specific attempts, ordering, and circuit-breaker handling without detailing retry implementation internals.
- Examples
- Uses producer timeout settings, Kafka Connect retry parameters, and JDBC connection attempts during database maintenance or network outages.
- What you can do after
- Operate/configure Kafka retries with bounded delays, total delivery deadlines, connector attempts, and persistent-failure handling.
Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform
A technique that repeats a failed operation a specified number of times, optionally pausing between attempts.
- How it is used
- Mitigates intermittent failures when microservices call external HTTP services.
- How deep it goes
- Explains bounded attempts, asynchronous wrappers, returned results, preserved errors, and pauses, without broader retry policy analysis.
- Examples
- Uses a failed-then-successful storage request, a JavaScript retry wrapper, and a retried Axios call.
- What you can do after
- Apply it via a JavaScript retry function around asynchronous operations such as Axios HTTP requests.
Distributed Machine Learning Patterns
A retry is the repeated execution of a failed workflow step.
- How it is used
- Uses retries to recover failed machine-learning workflow steps when the failure is temporary and rerunning can help.
- How deep it goes
- Explains root-cause analysis, dependency checks, resource checks, runtime metadata, and upstream restarts, but not retry code.
- Examples
- Uses failed model training, lost ingested data, preempted workers, out-of-memory errors, and memory-usage metadata.
- What you can do after
- Diagnose/debug with it by deciding whether to retry training, restore resources, or rerun data ingestion.
Read how Distributed Machine Learning Patterns explains retry →
Go in Practice, Second Edition
A retry is a repeated attempt to perform an operation after a failure, typically to recover from a transient problem.
- How it is used
- Uses bounded retries to recover HTTP connections and downloads after network timeouts.
- How deep it goes
- Explains timeout classification, resumable downloads, client timeouts, and recursive retry control, but not broader backoff policies.
- Examples
- Demonstrates timeout classification and a resumable file download using Go's HTTP client and Range requests.
- What you can do after
- Build a bounded, timeout-aware Go download retry using standard HTTP requests and partial-file resumption.
Python Concurrency with asyncio
Retry is a fault-tolerance technique that repeats a failed or timed-out operation to recover from a potentially transient failure.
- How it is used
- Handles transient downstream-service failures in asynchronous microservice HTTP requests.
- How deep it goes
- Provides a worked asyncio implementation with timeouts, delays, logging, and a terminal exception.
- Examples
- Demonstrates always-failing and always-timing-out coroutines, then applies retries to concurrent product, favorites, and cart requests.
- What you can do after
- Apply it via asyncio to retry bounded asynchronous operations and handle exhausted attempts explicitly.
Platform Engineering on Kubernetes
A retry mechanism automatically repeats a failed operation according to configured retry conditions and timing.
- How it is used
- Supports resilient service-to-service communication when requests fail temporarily.
- How deep it goes
- Explains exponential backoff and its rationale, but does not specify retry conditions, limits, or configuration.
- Examples
- Uses Service A and Service B to illustrate delayed retries during a failed interaction.
- What you can do after
- Evaluate how increasing retry delays can allow recovery while reducing request pressure on a failing service.
Read how Platform Engineering on Kubernetes explains retry →
Starting Data Analytics with Generative AI and Python
A recovery procedure that repeats a failed operation according to defined retry conditions.
- How it is used
- Stabilizes generative AI integrations by repeating failed requests after timeouts or rate-limit errors.
- How deep it goes
- Addresses retry mechanisms as error handling but does not specify backoff, attempt limits, or implementation code.
- Examples
- Uses timeouts and rate-limit errors as concrete failure cases requiring retry mechanisms.
- What you can do after
- Operate/configure generative AI integrations with retry mechanisms that improve stability during timeouts or rate-limit errors.
Read how Starting Data Analytics with Generative AI and Python explains retry →
Latency
A retry mechanism automatically attempts an operation again after a failed attempt.
- How it is used
- Handles transient failures in asynchronous processing and background synchronization without requiring user intervention.
- How deep it goes
- Details exponential backoff, idempotency, synchronization safeguards, and monitoring, but does not provide runnable implementation steps.
- Examples
- Uses failed message delivery, payment processing, and optimistic-update synchronization as concrete examples.
- What you can do after
- Diagnose retry effectiveness with attempt and success-rate metrics, and design safer recovery with backoff and idempotent operations.
Kotlin in Action, 2E
- How it is used
- Handles recoverable exceptions during Kotlin Flow collection without immediately terminating the operation.
- How deep it goes
- Explains predicate filtering, maximum attempts, full upstream re-execution, and side-effect safety, but not timing policies.
- Examples
- Demonstrates a random ten-emission flow that throws CommunicationException and retries collection with retry(5).
- What you can do after
- Apply it via Kotlin Flow's retry operator to selectively restart failed collection.
Related concepts
- exponential backoffuses · Exponential backoff is a retry strategy that progressively increases the delay between successive attempts after failures, typically by a multiplicative factor.
- transient failureaddresses · A transient failure is a temporary failure condition that may resolve on its own or not recur when an operation is attempted again.
- permanent failurecontrasts with · A permanent failure is a failure condition that is not resolved by repeating the same operation without changing the request or relevant system conditions.
- resilienceused by · Resilience is the capacity of a system or organization to withstand disruption, adapt, recover, or continue functioning acceptably.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.