fix: increase Ollama retry config + add transient-only mode

[fresh3nough]

Problem

When using Ollama with large models (e.g. Qwen3.5 35b), goose gives up after ~7 seconds with a 500 'connection refused' error. Ollama returns HTTP 500 while loading a model into memory, which can take 10-120s for large models on consumer hardware.

The default retry config (3 retries with 1s/2s/4s backoff = ~7s total) is insufficient for this scenario.

Fix

Override retry_config() in OllamaProvider with values tuned for local model loading:

• 10 retries (up from 3)
• 2s initial interval (up from 1s)
• 1.5x backoff multiplier (down from 2.0, more gradual ramp)
• 15s max interval (down from 30s)

This provides ~100s of total retry wait time (even with worst-case jitter, >60s), which handles models that take up to ~2 minutes to load.

Testing

• Added unit tests verifying the retry config values and that total wait time exceeds 60s
• All existing Ollama tests continue to pass
• cargo clippy clean

Closes #7635

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 616e2df1c5

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[DOsinga]

this does seem to change a lot more than just the retry for ollama

[fresh3nough]

in addition im updating pr title to extending transient mode

[DOsinga]

so I am thinking we shouldn't fix this using the retry mechanism - it would just retry any ollama call even the real faulty one > 1m. is there a different way of doing this? something that is more targeted to the issue

[fresh3nough]

gotcha, couple options:

Long First-Byte Timeout + Normal Chunk Timeout (builds on your earlier Ollama work) --> Use tokio::time::timeout only until the first SSE line/chunk arrives (like the “defer stall timeout” pattern we discussed before). --> After first chunk → revert to 30s per-chunk. --> This handles slow model loading without touching retries at all.

or

Smart Error-Pattern Retry Predicate
Only extend retries when the error matches known “model still loading” patterns:
Common Ollama signatures during cold start (from real issues + community reports):
HTTP 503 Service Unavailable
HTTP 500 with body containing: "llama runner", "loading model", "server not yet available", "timed out waiting for llama runner to start", or "model is loading"

In code: add a new method in OllamaProvider:Rustfn

is_model_loading_error(&self, err: &reqwest::Error) -> bool {
if err.status() == Some(StatusCode::SERVICE_UNAVAILABLE) { return true; }
let body = err.to_string().to_lowercase();
body.contains("llama runner") || body.contains("loading model") || ...
}

Then update the should_retry predicate to use this only for Ollama (and only up to ~120s total). Real errors fail instantly. This is precise, zero user impact, and easy to maintain

2 is more what I was thinking tbh

[DOsinga]

Clean fix — the transient_only mode correctly handles the Codex concern about 4xx errors getting the long Ollama backoff, the tests are meaningful, and the mechanical RetryConfig::new() updates to bedrock/databricks are the right approach now that transient_only is a private field. LGTM.