bug(sdk-python): Failed OTEL media uploads with openinference

[MJRuskin]

Describe the bug

When generating an image with Gemini, openinference will return the base64 in both the message parts and the final output.value field within the OTEL span.

Langfuse will attempt to upload both, which is fine, since the second upload would normally cancel automatically.

However, one of the images is actually urlsafe base64, which results in the invalid strings "-" and "_" to be dropped.
This causes two possible scenarios:

• Two separate medias are uploaded, one being the correct image, the other being an empty/failed image
• The resulting string is not %4 length, which results in an error, and the output value is replaced with an error message instead of the Langfuse media tag

While this could be considered an issue with the openinference, since that package is the recommended by Langfuse it would seem appropriate to handle this on the SDK side.

My suggestion would be to modify the following section to accept urlsafe base64:
https://github.com/langfuse/langfuse-python/blob/957d067d81ea357abf36c394bf68c7a8b184d53d/langfuse/media.py#L294

standardized_data = actual_data.replace("-", "+").replace("_", "/")
return base64.b64decode(standardized_data), cast(MediaContentType, content_type)

Steps to reproduce

• Install langfuse v4 and openinference-instrumentation-google-genai packages
• Generate an image using gemini

Langfuse Cloud or self-hosted?

Self-hosted

If self-hosted, what version are you running?

3.212

SDK and integration versions

langfuse v4.14.0
openinference-instrumentation-google-genai v1.2.0

Additional information

No response

Are you interested in contributing a fix for this bug?

Yes

[dosubot]

Hi @MJRuskin! I'm Dosu and I'm helping the Langfuse team.

I can confirm the issue. Looking at the _parse_base64_data_uri method in media.py, line 294 calls base64.b64decode(actual_data) directly on the raw data without any URL-safe base64 normalization. When openinference emits URL-safe base64 (using - and _ per RFC 4648 §5 instead of + and /), the standard decoder either silently drops those characters or raises a padding error depending on the resulting string length.

Your suggested fix is the right approach — normalizing URL-safe characters before decoding:

standardized_data = actual_data.replace("-", "+").replace("_", "/")
return base64.b64decode(standardized_data), cast(MediaContentType, content_type)

Alternatively, Python's base64.urlsafe_b64decode() handles this natively, but it requires proper = padding, so the replace-then-decode approach is more robust for data URIs that may or may not include padding.

Interestingly, the SDK already does the reverse conversion in _get_media_id() (converting standard base64 to URL-safe for media IDs), so the pattern is familiar to the codebase [1].

This fix would need to go into the langfuse-python repository.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[jasiecky]

Hey, I opened a fix.

@hassiebp @maxdeichmann @marcklingen

[MJRuskin]

@hassiebp
Please let me know if there's anything I can do to help with the review process.
The fix is only one line of code, but of course I realise that there are a number of other issues and PRs already in the backlog.