Embedding retries

[thomasstvr]

Summary

Fixes create.embeddings retries that stopped after the first failed HTTP or transport attempt, and adds a configurable per-attempt timeout.

The regression was introduced when embeddings adopted the shared OpenAI retry-classification helpers in #1124: requests.Response evaluates false for 4xx/5xx responses, so the old truthiness guard discarded the response context and classified retryable failures as permanent. This change checks response presence explicitly and keeps embeddings independent of extract.ai packaged defaults.

What changed

• Retry transient HTTP responses using the existing OpenAI policy for 408, 409, 429, and 5xx responses, including Retry-After.
• Retry transient request transport and response-transfer failures while failing permanent request errors immediately.
• Fail fast for OpenAI model_not_found responses without applying OpenAI-specific fatal handling to Jina.
• Expose and validate a per-attempt timeout in both wrangles.openai.embeddings and recipe create.embeddings.
• Validate retries and add focused mocked regression coverage using real false-valued requests.Response objects.
• Update the branch from current main.

Compatibility and behavior

• The default remains zero retries and a 30-second timeout, so callers that omit both parameters keep their existing timing behavior.
• retries means additional attempts. Each retry receives the full configured timeout; there is no total batch deadline.
• Existing OpenAI and Jina provider request/response formats are unchanged.
• Permanent HTTP/request errors fail after one attempt. Transient failures back off exponentially and honor Retry-After.

Validation

Passed locally with mocked network calls; no live OpenAI or Jina requests were made:

• 34 focused embeddings/provider/schema tests.
• 76 existing mocked extract.ai transport tests.
• Python compilation for the changed modules.
• git diff --check origin/main...HEAD.

GitHub CI will remain the authoritative full-suite check for the pushed head.

Risk and rollback

The primary risk is retry classification for less common requests transport failures. Tests cover connection, timeout, TLS, proxy, chunked-transfer, content-decoding, permanent URL, HTTP, authentication, and model errors.

Rollback by reverting the embeddings retry commits in this PR. No configuration migration or stored-data change is required.

[Copilot]

🟡 Changes recommended

The embedding retry loop still misses some transport failure cases and fatal-error semantics, and the new timeout/retry validation behavior isn’t covered by tests.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Fixes create.embeddings/wrangles.openai.embeddings retry behavior for transport failures and introduces a configurable per-attempt request timeout to make embedding generation more resilient.

Changes:

• Add timeout parameter to recipe create.embeddings and plumb it through to wrangles.openai.embeddings.
• Rework embedding retry loop to handle timeouts/connection failures and improve retry logging/error messages.
• Add input validation for retries and timeout in wrangles.openai.embeddings.

Recommended disposition: Request changes

Next steps

1. PR assignee: Apply the inline fixes in wrangles/openai.py (broaden transport exception handling; raise fatal OpenAI errors consistently) and add tests covering timeout pass-through + validation.
2. Reviewer: Verify the updated retry behavior with mocked transport failures and confirm the new timeout parameter is exercised; then resolve threads and re-review.

File summaries

File	Description
wrangles/recipe_wrangles/create.py	Exposes timeout in the recipe-facing create.embeddings API/schema and forwards it to the OpenAI embeddings backend.
wrangles/openai.py	Implements per-attempt timeout, fixes retry semantics for transport errors, and tightens parameter validation/error reporting for embeddings.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 3
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.