| 1 |
<?php |
| 2 |
/** |
| 3 |
* Request-timeout classification for AI HTTP clients. |
| 4 |
* |
| 5 |
* @package ThinkRank\AI\Traits |
| 6 |
*/ |
| 7 |
|
| 8 |
declare(strict_types=1); |
| 9 |
|
| 10 |
namespace ThinkRank\AI\Traits; |
| 11 |
|
| 12 |
if (!defined('ABSPATH')) { |
| 13 |
exit; |
| 14 |
} |
| 15 |
|
| 16 |
/** |
| 17 |
* Shared timeout detection for the clients that own a request_with_retry() loop. |
| 18 |
* |
| 19 |
* OpenAI, Claude and Gemini each carried an identical copy of is_timeout_error(); |
| 20 |
* a change to how a timeout is recognised had to be made in three places or the |
| 21 |
* retry behaviour would diverge between providers (issue #288). This trait is the |
| 22 |
* single copy they all use. |
| 23 |
*/ |
| 24 |
trait Request_Timeout { |
| 25 |
|
| 26 |
/** |
| 27 |
* Whether a WP_Error from the WordPress HTTP API is a client-side timeout. |
| 28 |
* |
| 29 |
* A cURL timeout (error 28) surfaces as the 'http_request_failed' code with |
| 30 |
* a message containing "Operation timed out" / "timed out". WP_Error codes |
| 31 |
* are not a stable contract across HTTP transports, so match the message |
| 32 |
* too, and treat ONLY a recognised timeout as non-retryable — any other |
| 33 |
* network failure (DNS, connection refused, TLS) keeps the existing retry |
| 34 |
* behaviour so this cannot make an unrelated transient failure worse. |
| 35 |
* |
| 36 |
* @param \WP_Error $error The error returned by wp_remote_request(). |
| 37 |
* @return bool True if the error represents a request timeout. |
| 38 |
*/ |
| 39 |
private function is_timeout_error(\WP_Error $error): bool { |
| 40 |
foreach ((array) $error->get_error_messages() as $message) { |
| 41 |
if (stripos((string) $message, 'timed out') !== false |
| 42 |
|| stripos((string) $message, 'timeout') !== false) { |
| 43 |
return true; |
| 44 |
} |
| 45 |
} |
| 46 |
return false; |
| 47 |
} |
| 48 |
} |
| 49 |
|
