# `Nous.Errors.RetryInfo`
[🔗](https://github.com/nyo16/nous/blob/v0.17.1/lib/nous/errors/retry_info.ex#L1)

Parse server-suggested retry delays from provider error responses.

Two sources are checked, body first then headers:

1. **Body** — Google APIs (Vertex AI, Gemini) embed
   `google.rpc.RetryInfo` inside `error.details[]` with a
   `retryDelay` field as a `google.protobuf.Duration` string
   (e.g. `"34s"`, `"1.500s"`).
2. **Headers** — Standard HTTP `Retry-After` (RFC 7231). Integer
   seconds is supported; HTTP-date form is intentionally not handled
   here as no LLM provider in production uses it for rate limits.

Returns the suggested delay in **milliseconds**, or `nil` when no
hint is available. A missing hint is itself meaningful for Google
APIs — daily/long-term quota exhaustion deliberately omits
`RetryInfo` to discourage retry loops, so callers should treat
`nil` as "do not auto-retry".

# `parse`

```elixir
@spec parse(any()) :: pos_integer() | nil
```

Extract a retry delay (ms) from an HTTP error tuple's payload.

Accepts the shape produced by `Nous.HTTP.Backend` implementations:
`%{status: integer, body: term, headers: list}`. Missing fields are
tolerated.

## Examples

    iex> RetryInfo.parse(%{
    ...>   status: 429,
    ...>   body: %{"error" => %{"details" => [
    ...>     %{"@type" => "type.googleapis.com/google.rpc.RetryInfo",
    ...>       "retryDelay" => "34s"}
    ...>   ]}}
    ...> })
    34_000

    iex> RetryInfo.parse(%{status: 429, headers: [{"retry-after", "60"}]})
    60_000

    iex> RetryInfo.parse(%{status: 429, body: %{"error" => %{"message" => "rate limited"}}})
    nil

---

*Consult [api-reference.md](api-reference.md) for complete listing*