Skip to content

[INT-715] Retry transient failures when verifying OpenAI keys - #5117

Merged
bill-rich merged 3 commits into
mainfrom
openai-verify-retry
Jul 8, 2026
Merged

[INT-715] Retry transient failures when verifying OpenAI keys#5117
bill-rich merged 3 commits into
mainfrom
openai-verify-retry

Conversation

@bill-rich

@bill-rich bill-rich commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Description

During bulk reverification, an OpenAI key verification failed with context deadline exceeded (Client.Timeout exceeded while awaiting headers) and was recorded as an indeterminate result. The detector's default client was common.SaneHttpClient(): a 5s timeout with no retries, so any single slow response from the OpenAI API becomes a permanent verification failure.

This switches the default client to common.RetryableHTTPClient (the same pattern already used by the twilio and privatekey detectors) with:

  • 10s per-attempt timeout (the OpenAI API can be slow to respond under load)
  • Up to 2 retries with exponential backoff on transient failures (timeouts, connection errors, 429/5xx)

The retryable client respects the parent context, so callers with their own deadlines still bound the total time. Scanners constructed with an explicit client are unaffected.

Adds a unit test asserting the default client retries transient errors (500, 500, then 200 → exactly 3 attempts, final 200).

Checklist

  • Tests passing (go test ./pkg/detectors/openai/)
  • go vet and gofmt clean

Note

Low Risk
Scoped to OpenAI detector verification HTTP behavior; may slightly increase verification latency on failures but reduces false indeterminate results.

Overview
OpenAI key verification no longer treats a single slow or flaky API response as an indeterminate result during bulk reverification.

The detector’s default HTTP client is switched from common.SaneHttpClient() (5s timeout, no retries) to common.RetryableHTTPClient with a 10s per-attempt timeout and up to 2 retries on transient failures (timeouts, connection errors, 429/5xx), matching patterns used by detectors such as Twilio and privatekey. Scanners that inject their own client are unchanged.

Unit tests assert the default client retries until success (500 → 500 → 200, three attempts) and stops after the retry budget when errors persist.

Reviewed by Cursor Bugbot for commit 84b316c. Bugbot is set up for automated code reviews on this repo. Configure here.

The OpenAI verification endpoint can be slow to respond under load,
and a single 5s client timeout was recorded as an indeterminate
verification result with no retry. Switch the default client to the
common retryable client with a 10s per-attempt timeout and up to 2
retries with backoff on timeouts, connection errors, and 429/5xx
responses.
@bill-rich
bill-rich requested a review from a team July 8, 2026 16:28
@bill-rich
bill-rich requested a review from a team as a code owner July 8, 2026 16:28
@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown

Corpora Test Results

No detector regex or keyword changes in this PR. Bench skipped.

@bill-rich bill-rich changed the title Retry transient failures when verifying OpenAI keys [INT-715] Retry transient failures when verifying OpenAI keys Jul 8, 2026

@martinlocklear martinlocklear left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add at least one test case for the failure path, but maybe that's already covered elsewhere?

@bill-rich
bill-rich merged commit 33d9dad into main Jul 8, 2026
16 checks passed
@bill-rich
bill-rich deleted the openai-verify-retry branch July 8, 2026 22:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants