feat: add CURLRequest retry option#10157
Open
memleakd wants to merge 4 commits intocodeigniter4:4.8from
Open
Conversation
- Add retry support for failed HTTP responses - Support configurable attempts, delays, status codes, and Retry-After - Add opt-in retries for transient cURL errors - Document retry behavior and safety considerations - Add focused CURLRequest retry tests Signed-off-by: memleakd <121398829+memleakd@users.noreply.github.com>
patel-vansh
suggested changes
May 4, 2026
Contributor
patel-vansh
left a comment
There was a problem hiding this comment.
Overall this feature is a nice addition. Thanks! I always wanted a similar feature. Just few thoughts
ddevsr
reviewed
May 4, 2026
- Add 504 Gateway Timeout to default retryable status codes - Reuse stored cURL error number when throwing - Add coverage for default 504 retry behavior Signed-off-by: memleakd <121398829+memleakd@users.noreply.github.com>
michalsn
reviewed
May 4, 2026
Signed-off-by: memleakd <121398829+memleakd@users.noreply.github.com>
samsonasik
reviewed
May 4, 2026
Signed-off-by: memleakd <121398829+memleakd@users.noreply.github.com>
michalsn
approved these changes
May 5, 2026
Member
michalsn
left a comment
There was a problem hiding this comment.
Overall, I like it. The user guide is clear enough to me.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR proposes adding
retryoption toCURLRequest.Modern applications often depend on external APIs for payments, notifications, search, analytics, AI services, webhooks, and internal service-to-service calls. These requests can fail temporarily because of rate limits, short outages, gateway errors, DNS/connectivity issues, or upstream overload. Today, users need to write this retry flow manually around
CURLRequest.This PR adds a small, opt-in retry layer directly to
CURLRequestso common transient failures can be handled in a framework-native way.For simple cases, users can pass an integer retry count:
For more control, users can pass an array:
The feature is intentionally contained within
CURLRequestand does not change existing request behavior unlessretryis explicitly configured.Behavior and Defaults
retrymay be an integer retry count or an array of retry settings.max_retriesis the number of retries after the initial request.delayis in milliseconds and may be a fixed integer or a simple backoff array.status_codesdefaults to[429, 503, 504], covering rate limiting and service unavailability without retrying every server error by default.respect_retry_afterdefaults totrue, so validRetry-Afterheaders are honored.max_delaydefaults to30000ms to avoid unexpectedly long blocking waits in synchronous PHP processes.max_delaycaps both configured delays and validRetry-Aftervalues. Users can set it to0for no cap.curl_errorsdefaults tofalse; transient cURL/network retries are available explicitly withcurl_errors => true.http_errorsis enabled, retryable HTTP errors are retried first. If retries are exhausted, the final HTTP error still throws as expected.POSTandPATCHare not blocked, but the docs warn that the remote server may receive the request more than once.Design Notes
The API is deliberately small:
'retry' => 3.Retry-Afterbehavior.CURLRequestitself is synchronous.max_delayprotects PHP-FPM workers, queue workers, and long-running processes from accidentally sleeping for a very long server-suppliedRetry-After.Documentation
The user guide documents:
Retry-Afterpriority and max delay behavior.http_errors.Tests
Tests cover:
Retry-Afterseconds and HTTP-date handling.max_delaycap.Retry-Afterhandling.http_errorsenabled.http_errorsdisabled.Checklist: