fix: add retry logic for OpenAI embedding API failures

[superlowburn]

Fixes #149

Problem

Users encountered "Server Error" when importing or uploading skills. The root cause was transient failures in the OpenAI embedding API call (rate limits, timeouts, network issues) causing the entire import to fail with an unhelpful error message.

Solution

Added retry logic with exponential backoff to generateEmbedding():

• Retries on: 429 (rate limit), 5xx server errors, network/fetch errors
• Backoff: 1s, 2s, 4s delays (max 3 retries)
• Logging: Clear warnings for debugging
• Failure mode: After retries exhausted, fails with clear error message

Testing

• ✅ All existing tests pass (400 tests)
• ✅ No test assertions changed
• ✅ Verified the fix handles transient API failures gracefully

Notes

This is a defensive fix for a transient issue. The comment from @swairshah on Feb 6 ("This seems fixed now") suggests the underlying API issue may have resolved, but this adds resilience to prevent future occurrences.

Greptile Overview

Greptile Summary

This PR adds retry logic with exponential backoff to convex/lib/embeddings.ts’s generateEmbedding() to make skill import/upload more resilient to transient OpenAI embeddings API failures.

The change wraps the embeddings fetch() in a retry loop, retrying on 429/5xx responses and certain thrown errors, logging warnings and ultimately surfacing a clearer Embedding failed: ... error that upstream publish flows already map into user-friendly messages.

Confidence Score: 3/5

• This PR is close to mergeable but has a couple of retry-logic correctness issues that should be fixed first.
• Core idea (retry on 429/5xx) is sound and integrates cleanly with existing publish error formatting, but the loop currently performs more attempts than intended with misleading attempt logging, and the network-error retry predicate is too narrow and can skip retries for common transient failures.
• convex/lib/embeddings.ts

_{Last reviewed commit: 87cb005}

Context used:

• Context from dashboard - AGENTS.md (source)

[vercel]

@superlowburn is attempting to deploy a commit to the Amantus Machina Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

_{1 file reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Off-by-one retry loop

for (let attempt = 0; attempt <= maxRetries; attempt++) with maxRetries = 3 performs 4 total fetch attempts (0..3), but the warning log prints attempt ${attempt + 1}/${maxRetries}, which reports only 1/3..3/3 and never reflects the final attempt. This also makes the actual backoff sequence longer than intended under persistent failures.

Prompt To Fix With AI

This is a comment left during a code review.
Path: convex/lib/embeddings.ts
Line: 18:22

Comment:
**Off-by-one retry loop**

`for (let attempt = 0; attempt <= maxRetries; attempt++)` with `maxRetries = 3` performs **4 total** fetch attempts (0..3), but the warning log prints `attempt ${attempt + 1}/${maxRetries}`, which reports only `1/3..3/3` and never reflects the final attempt. This also makes the actual backoff sequence longer than intended under persistent failures.

How can I resolve this? If you propose a fix, please make it concise.

[superlowburn]

Valid catch. The loop runs 4 times (0..3) but the log only reflects 3. Will fix to attempt < maxRetries and update the log to ${attempt + 1}/${maxRetries} consistently.

[greptile-apps]

Network retries may not trigger

The retry path for thrown errors is gated on error instanceof Error && error.message.includes('fetch'). Many real network/timeouts (e.g., socket errors) won't include 'fetch' in the message (or may not be an Error), so transient network failures can still fail immediately without retrying, undermining the stated goal of handling network/fetch errors.

Prompt To Fix With AI

This is a comment left during a code review.
Path: convex/lib/embeddings.ts
Line: 55:58

Comment:
**Network retries may not trigger**

The retry path for thrown errors is gated on `error instanceof Error && error.message.includes('fetch')`. Many real network/timeouts (e.g., socket errors) won't include `'fetch'` in the message (or may not be an `Error`), so transient network failures can still fail immediately without retrying, undermining the stated goal of handling network/fetch errors.

How can I resolve this? If you propose a fix, please make it concise.

[superlowburn]

Good catch — error.message.includes('fetch') is too narrow. Socket hangups, DNS failures, and timeouts won't include that string. Will broaden to catch any Error on retry attempts instead of filtering by message content.