[as992949791]

What does this PR do?

An explicit encoding_format="base64" leaves the embedding as a string in the OpenAI SDK. Langfuse currently records that string's character count as the vector dimensions: a three-dimensional float32 embedding is reported as 16 dimensions.

Count the decoded float32 elements for base64 responses. Float-array responses keep their current behavior, and the SDK response is returned unchanged. The exported output still contains only dimensions and count. If a provider returns malformed base64, decoding falls back to the previous string-length result without changing the SDK passthrough. Only decoding errors are caught; SDK call errors retain their existing behavior.

- {"dimensions": 16, "count": 1}
+ {"dimensions": 3, "count": 1}

Type of change

• Bug fix

Verification

uv run --frozen pytest tests/unit/test_openai.py tests/unit/test_openai_prompt_extraction.py tests/unit/test_parse_usage_model.py
uv run --frozen ruff check .
uv run --frozen ruff format --check langfuse/openai.py tests/unit/test_openai.py
uv run --frozen mypy langfuse --no-error-summary

75 tests passed; Ruff and mypy passed. All five new cases use the real OpenAI response parser with httpx.MockTransport and the shared in-memory exporter. No live provider or Langfuse server calls were made.

Evidence

Before: the three valid-base64 export regressions fail on upstream, reporting string lengths instead of 1, 2, or 3 dimensions. After: all five new cases pass, including malformed-base64/non-ASCII passthrough and equality of the SDK-returned embedding string. The existing float-array export regression also passes.

Merge Danger

Door: two-way. Blast Radius: embedding trace output for explicit base64 responses. No public signatures or provider responses change.

Checklist

• I self-reviewed the diff using code_review.md (Codex review).
• I added or updated tests for behavior changes.
• I updated docs, examples, or .env.template if needed. No documentation becomes stale from correcting this count.
• I did not hand-edit generated files; if generated files changed, I used the upstream regeneration path.
• I did not commit secrets or credentials.

AI disclosure: The implementation, regression tests, and self-review were produced with OpenAI Codex. No human review is claimed.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking gap in the malformed-response fallback.

Summary

Corrects embedding dimension counts by decoding base64 strings and counting float32 elements.

• Base64 embedding traces now show the vector’s actual dimension count.

_{Reviews (1) · Last reviewed commit: "fix(openai): preserve malformed embeddin..." · Reviewed by Greptile}

[claude]

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]

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.}

[greptile-apps]

Malformed strings bypass the fallback

base64.b64decode silently discards invalid characters by default. A provider response of "!!!!" therefore exports 0 dimensions instead of the previous 4. Likewise, "AAAA" decodes to three bytes, which // 4 truncates to 0 despite not containing a complete float32.

Use strict decoding and check that the decoded length is divisible by four before counting dimensions. Add both cases to the fallback tests.

Prompt To Fix With AI

This is a comment left during a code review.
Path: langfuse/openai.py
Line: 971

Comment:
**Malformed strings bypass the fallback**

`base64.b64decode` silently discards invalid characters by default. A provider response of `"!!!!"` therefore exports 0 dimensions instead of the previous 4. Likewise, `"AAAA"` decodes to three bytes, which `// 4` truncates to 0 despite not containing a complete float32.

Use strict decoding and check that the decoded length is divisible by four before counting dimensions. Add both cases to the fallback tests.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.