feat(openai)!: drop support for OpenAI SDK versions below 1.0

[hassiebp]

What does this PR do?

The OpenAI integration now assumes openai >=1.0:

• removes OPENAI_METHODS_V0 and every _is_openai_v1() branch in langfuse/openai.py (v1 client shapes only)
• dev dependency openai>=0.27.8 → openai>=1.0.0 (one-line uv.lock change, verified with uv lock --check)

The pre-1.0 branches were already unreachable: langfuse/openai.py imports openai._types.NotGiven at module level, which does not exist in openai 0.x.

Stack: 2 of 10. Base: #1927. Merge after #1927. It is stacked only because both PRs edit pyproject.toml/uv.lock; the hunks don't overlap.

Type of change

• Bug fix
• New feature
• Breaking change
• Refactor
• Documentation update
• Tooling, CI, or repo maintenance

Verification

uv run --frozen ruff check .                       # All checks passed!
uv run --frozen mypy langfuse --no-error-summary   # clean
uvx uv@0.11.2 lock --check                         # Resolved 91 packages
uv run --frozen pytest -n auto tests/unit/test_openai.py tests/unit/test_openai_prompt_extraction.py  # 60 passed
uv run --frozen pytest -n auto tests/unit          # 713 passed, 2 skipped

tests/live_provider/test_openai.py needs a real OpenAI key and was not run locally; CI runs it.

Checklist

• I self-reviewed the diff using code_review.md.
• I added or updated tests for behavior changes.
• I updated docs, examples, or .env.template if needed.
• I did not hand-edit generated files; if generated files changed, I used the upstream regeneration path.
• I did not commit secrets or credentials.

  

Confidence Score: 5/5

The PR appears safe to merge as the stated breaking change.

Summary

The PR removes pre-1.0 OpenAI integration branches and raises the development dependency minimum to OpenAI 1.0.

• Supported OpenAI 1.x execution paths retain their prior behavior.
• The lockfile reflects the updated development dependency specifier.

_{Reviews (1) · Last reviewed commit: "feat(openai)!: drop support for OpenAI S..."}

[github-actions]

@claude review

[claude]

Claude Code Review

No review was started: this request came from a bot account. Manual reviews can only be requested by someone with write access to this repository. Ask a maintainer to comment @claude review, or have your automation post the comment from a user account with write access.

_{Tip: disable this comment in your organization's Code Review settings.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-06T14:32:10.549082Z	ee38a2b	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[claude]

Looks good — straightforward dead-code removal plus a matching version-floor bump.

What was reviewed: the _is_openai_v1() branch removals in _extract_streamed_openai_response, _get_langfuse_data_from_default_response, _is_streaming_response, _install_openai_stream_iteration_hooks, _wrap/_wrap_async, and register_tracing; confirmed each removed branch always took the v1 path. Checked that langfuse/openai.py already imports openai._types.NotGiven at module level (line 36), which doesn't exist pre-1.0, so the v0 branches were unreachable even before this change. Verified the pyproject.toml/uv.lock dev-dependency bump (openai>=0.27.8 → >=1.0.0) is a one-line, consistent change in both files.

Extended reasoning...

The change removes OPENAI_METHODS_V0 and all _is_openai_v1() conditional branches in langfuse/openai.py, always taking the openai>=1.0 code path, and bumps the dev dependency floor in pyproject.toml/uv.lock to match. No security-sensitive surface (auth, crypto, permissions) is touched. The decisive fact is that the module already hard-required openai>=1.0 via a module-level import of openai._types.NotGiven, making the removed branches provably dead code, so this is a mechanical simplification with no behavior change.