Skip to content

fix(test): set TEST_KEY before OpenAILLMClient in guardrail test#1280

Merged
muddlebee merged 1 commit intoTracer-Cloud:mainfrom
muddlebee:chore/openai-sdk-pin-guardrail-test
May 4, 2026
Merged

fix(test): set TEST_KEY before OpenAILLMClient in guardrail test#1280
muddlebee merged 1 commit intoTracer-Cloud:mainfrom
muddlebee:chore/openai-sdk-pin-guardrail-test

Conversation

@muddlebee
Copy link
Copy Markdown
Collaborator

@muddlebee muddlebee commented May 4, 2026

Summary

OpenAI 2.34+ rejects an empty api_key in OpenAI(). TestOpenAIClientGuardrails::test_redacts_before_api_call constructed OpenAILLMClient before setting TEST_KEY, so CI failed once the resolver picked 2.34.x.

Change

  • Set TEST_KEY before instantiating OpenAILLMClient (same order as the openai_capture fixture).

No dependency cap: staying on openai>=2.0.0 and fixing the test is sufficient.

@muddlebee muddlebee changed the title fix(deps): cap openai below 2.34 and fix guardrail test fix(test): set TEST_KEY before OpenAILLMClient in guardrail test May 4, 2026
OpenAI 2.34+ rejects an empty api_key in OpenAI(). Match openai_capture fixture order.
@muddlebee muddlebee force-pushed the chore/openai-sdk-pin-guardrail-test branch from 7d68370 to 6a97775 Compare May 4, 2026 18:10
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented May 4, 2026

Greptile Summary

This PR fixes a CI breakage caused by openai 2.34.0 rejecting construction with an empty credential. It pins openai to <2.34.0 and reorders the test setup so the env var is set before OpenAILLMClient is instantiated.

The test reordering is correct and necessary regardless of the version pin. The pin itself is a valid short-term fix, but the underlying issue is that OpenAILLMClient.__init__ eagerly calls OpenAI(...) with a potentially empty credential — the existing _ensure_client method already handles lazy/re-keyed creation correctly, so deferring construction there would be the permanent fix that removes the need for the cap.

Confidence Score: 4/5

Safe to merge as a short-term CI fix; the version cap and test fix are both correct, with a known follow-up needed in the production client.

Only P2 findings present. The changes are small, targeted, and correct. The pin is acknowledged as temporary and the test fix is unambiguously right. No regressions introduced.

app/services/llm_client.py — the eager OpenAI(...) call in __init__ is the root cause and should be addressed in a follow-up.

Important Files Changed

Filename Overview
pyproject.toml Caps openai to <2.34.0 to avoid empty-credential rejection at construction; band-aid until OpenAILLMClient.__init__ is refactored for lazy client creation.
tests/test_guardrails/test_llm_integration.py Reorders monkeypatch.setenv to precede OpenAILLMClient construction — correct fix that mirrors what real usage requires.

Comments Outside Diff (1)

  1. app/services/llm_client.py, line 257-259 (link)

    P2 Eager client construction with empty credential is the root cause

    __init__ always calls OpenAI(...) at line 257 even when the resolved credential is an empty string — exactly what openai 2.34+ now rejects. The test fix and the <2.34.0 pin together work around this for now, but once the pin is lifted the production code will break again for any caller that constructs OpenAILLMClient before its env var is populated.

    _ensure_client already implements the lazy/re-keyed construction pattern correctly. Deferring the initial OpenAI(...) call there — setting self._client = None in __init__ and letting _ensure_client create it on first use — would make the class fully compatible with 2.34+ and allow the version cap to be removed.

Reviews (1): Last reviewed commit: "fix(test): set TEST_KEY before OpenAILLM..." | Re-trigger Greptile

@muddlebee muddlebee merged commit 588a231 into Tracer-Cloud:main May 4, 2026
10 checks passed
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 4, 2026

🎻 "The diff was clean, the tests did pass, the reviewer wept." That poem was about @muddlebee's PR. 🥹


👋 Join us on Discord - OpenSRE : hang out, contribute, or hunt for features and issues. Everyone's welcome.

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.

1 participant