fix(otel): detect base64 data URIs with media-type parameters

[i-anubhav-anand]

The media-extraction regex in MediaService requires ;base64 to immediately follow the content type:

const regex = /data:[^;]+;base64,[A-Za-z0-9+/]+=*/g;

So a valid RFC 2397 data URI with a media-type parameter never matches:

data:text/plain;charset=utf-8;base64,SGVsbG8=   // [^;]+ stops at the first ";"

The result: the media is not extracted/uploaded, and the raw base64 stays embedded verbatim in the exported attribute (payload bloat + the upload is silently skipped). Plain data:image/png;base64,… works only because it has no parameter.

The downstream parser (@langfuse/core parseBase64DataUri) is already parameter-aware (header.split(";")), so the extraction regex was stricter than the parser it feeds. Fix matches any non-comma run up to ;base64,:

const regex = /data:[^,]*;base64,[A-Za-z0-9+/]+=*/g;

Test

Adds an integration test embedding data:text/plain;charset=utf-8;base64,… and asserting it is replaced with a @@@langfuseMedia:…@@@ tag. Fails before (URI left embedded), passes after. Existing media tests still pass; prettier/eslint/tsc clean (pre-commit).

Type of change

• Bug fix (non-breaking change which fixes an issue)

Greptile Summary

This PR fixes a regex in MediaService that failed to match RFC 2397 data URIs containing media-type parameters (e.g. data:text/plain;charset=utf-8;base64,…), causing those URIs to be left embedded verbatim instead of being extracted and uploaded. The fix narrows the matching expression from [^;]+ (stops at first ;) to [^,]* (stops at first ,, covering the full header), aligned with how the downstream parseBase64DataUri parser already handles parameters.

• packages/otel/src/MediaService.ts: single-character class change in the detection regex, with an explanatory comment added.
• tests/integration/span-processor.integration.test.ts: new integration test that embeds a parameterised data URI and asserts it is replaced with a @@@langfuseMedia:…@@@ tag.

Confidence Score: 5/5

Safe to merge — the change is a single-character class adjustment in a detection regex, well-covered by a new integration test, and consistent with the downstream parser.

The regex fix is minimal and well-reasoned: greedy backtracking on [^,]*;base64, correctly locates the last ;base64, before the MIME-type/data boundary for both plain and parameterised URIs. The new integration test directly exercises the previously-broken path and confirms replacement. Existing tests continue to cover the simple image/png;base64 case. No unrelated code is touched.

No files require special attention.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Span attribute value string] --> B{Regex match on value}
    B -- No match --> C[Skip attribute]
    B -- Match found --> D[Deduplicate matches]
    D --> E[For each data URI]
    E --> F[Create LangfuseMedia object]
    F --> G{Get media tag}
    G -- Failure --> H[Log warn, skip item]
    G -- Success --> I[Schedule upload]
    I --> J[Replace URI with langfuseMedia tag]
    J --> K[Write updated value back to span attributes]
    K --> E

Loading

_{Reviews (1): Last reviewed commit: "fix(otel): detect base64 data URIs with ..." | Re-trigger 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.

[vercel]

@i-anubhav-anand is attempting to deploy a commit to the langfuse Team on Vercel.

A member of the Team first needs to authorize it.