Skip to content

fix(langchain): read AzureOpenAI API version from openai_api_version#1649

Open
Spectual wants to merge 1 commit intolangfuse:mainfrom
Spectual:fix/langchain-azure-openai-version-key
Open

fix(langchain): read AzureOpenAI API version from openai_api_version#1649
Spectual wants to merge 1 commit intolangfuse:mainfrom
Spectual:fix/langchain-azure-openai-version-key

Conversation

@Spectual
Copy link
Copy Markdown

@Spectual Spectual commented May 9, 2026

Summary

_extract_model_name for AzureOpenAI checks
serialized_kwargs[\"openai_api_version\"] to decide whether a version is
available, then reads the value from serialized_kwargs[\"deployment_version\"]
(langfuse/langchain/utils.py:73-74):

if serialized_kwargs.get(\"openai_api_version\"):
    deployment_version = serialized_kwargs.get(\"deployment_version\")

LangChain's AzureOpenAI doesn't expose a deployment_version field — only
openai_api_version and deployment_name. So deployment_version is always
None, the isinstance(deployment_version, str) check at line 82 fails, and
the function returns the bare deployment name with no version suffix even
when the API version is available.

This makes the version suffix that PR #1203 ("fix(langchain): deployment
version in azure model") was trying to keep deduplicated effectively
unreachable for callers who set openai_api_version but use a
deployment_name without an embedded version.

Fix

Read the value from the same key that gates the branch (openai_api_version).
Combined with the dedup logic from #1203, deployments now produce
<deployment_name>-<api_version> while still collapsing if the
deployment_name already embeds the version.

 if serialized_kwargs.get(\"openai_api_version\"):
-    deployment_version = serialized_kwargs.get(\"deployment_version\")
+    deployment_version = serialized_kwargs.get(\"openai_api_version\")

Tests

tests/unit/test_extract_model_name.py (new) covers three regression cases:

  1. api_version present → \"my-deployment-2024-02-15-preview\" (was
    \"my-deployment\" before this fix).
  2. api_version absent → \"my-deployment\" (unchanged).
  3. deployment_name already contains the version → no duplication
    (preserves fix(langchain): deployment version in azure model #1203's behavior).

I verified the function-level logic by importing _extract_model_name
directly and exercising all three cases against a stubbed serialized dict
that mirrors what LangChain emits — pre-fix the first case returns
\"my-deployment\", post-fix it returns \"my-deployment-2024-02-15-preview\".
The repo's full uv env wasn't set up in my sandbox, so CI is the canonical
end-to-end run.

Disclaimer: Experimental PR review

Greptile Summary

This PR fixes a one-line key-name mistake in _extract_model_name for AzureOpenAI: the branch gated on openai_api_version then read from the non-existent deployment_version, so the version suffix was always silently dropped. The fix reads from the same key that guards the branch.

  • langfuse/langchain/utils.py: Changes serialized_kwargs.get(\"deployment_version\") to serialized_kwargs.get(\"openai_api_version\"), making the version lookup consistent with the conditional that gates it.
  • tests/unit/test_extract_model_name.py: Adds three focused regression tests covering: version present → appended, version absent → bare deployment name, and version already embedded in name → no duplication.

Confidence Score: 5/5

Safe to merge — the change is a one-line key-name fix with no side effects on other model paths.

The fix correctly aligns the value lookup with the key already used in the conditional guard. The surrounding deduplication logic is untouched, and three targeted regression tests verify the before/after behavior. No other code paths are affected.

No files require special attention.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[_extract_model_name called] --> B{AzureOpenAI in serialized_id?}
    B -- No --> C[Try other model matchers]
    B -- Yes --> D{invocation_params has model or model_name?}
    D -- Yes --> E[Return invocation_params value]
    D -- No --> F{openai_api_version present in serialized_kwargs?}
    F -- Yes --> G["deployment_version = openai_api_version value FIXED: was deployment_version key, always None"]
    F -- No --> H[deployment_version = None]
    G --> I{deployment_name present?}
    H --> I
    I -- No --> J[Return None]
    I -- Yes --> K[deployment_name = serialized_kwargs value]
    K --> L{deployment_version is str?}
    L -- No --> M[Return bare deployment_name]
    L -- Yes --> N{version already in deployment_name?}
    N -- Yes --> O[Return deployment_name unchanged]
    N -- No --> P[Return deployment_name + version suffix]
Loading

Reviews (1): Last reviewed commit: "fix(langchain): read AzureOpenAI API ver..." | Re-trigger Greptile

`_extract_model_name` for `AzureOpenAI` checks
`serialized_kwargs["openai_api_version"]` to decide whether a version
is available, then reads the value from `serialized_kwargs["deployment_version"]`
(`langfuse/langchain/utils.py:73-74`). LangChain's `AzureOpenAI` doesn't
expose a `deployment_version` field — only `openai_api_version` and
`deployment_name` — so `deployment_version` is always `None`, the
`isinstance(deployment_version, str)` check fails, and the function
returns the bare deployment name with no version suffix.

Read the value from the same key that gates the branch
(`openai_api_version`). Combined with the deduplication logic added in
PR langfuse#1203, deployments now produce `<deployment_name>-<api_version>` —
matching the documented intent of this code path — while still
collapsing if the deployment_name already embeds the version.

Add `tests/unit/test_extract_model_name.py` with three regression cases:
api_version present, api_version absent, and the dedup path from langfuse#1203.
Copy link
Copy Markdown

@claude claude Bot left a comment

Choose a reason for hiding this comment

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

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

@CLAassistant
Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

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