[feature request] LangChain Auto-Instrumentor Should Normalize JSON MIME

[arizedatngo]

• Summary
  LangChain’s OpenInference auto-instrumentor only tags input/output.mime_type as application/json when the payload is a Python dict/list. When the producer hands stringified JSON, the tracer leaves the MIME as text/plain, so the frontend can’t render pretty JSON.

• Environment

  • openinference-instrumentation-langchain 0.1.35–0.1.54 (current release)
  • LangChain auto-instrumentation only; no custom span processor.

• Steps to Reproduce

  1. Run a LangChain chain whose input/output values are JSON strings (e.g., {"input": "{\"name\": \"Ada\"}"}) rather than dicts.
  2. Observe the emitted span attributes: input.value contains the JSON string, but input.mime_type (and output.mime_type) remain text/plain.
  3. Frontend receives text/plain and renders raw text instead of the JSON renderer.

• Expected Behavior
  Any payload that can be parsed as JSON (or whose MIME already contains a JSON subtype) should reach the span with input/output.mime_type = "application/json" so the UI knows to prettify it.

• Actual Behavior
  _convert_io returns early for string values, so input/output.mime_type is never updated. _normalize_mime_type rejects values like text/plain; charset=utf-8, so there’s no later chance to fix it. UI renders as plain text.

• Proposed Fix Not sure if Correct or not so please check
  Extend _convert_io (or a dedicated helper) to re-parse string values:

  • When the sole input/output value is a str, attempt json.loads. If parsing succeeds and yields a dict/list, emit the serialized JSON string plus OpenInferenceMimeTypeValues.JSON.value.
  • Optionally normalize incoming MIME strings (lowercase, strip ; charset=..., treat any subtype containing "json" as JSON) before storing them.
  • Add unit tests covering stringified JSON and MIME variants (e.g., application/json; charset=utf-8).

[arizedatngo]

should we fix instrumentation or UI logic

[caroger]

discussed with @RogerHYang , we can and should fix it on the instrumentation side.

• we need a helper like _is_json_parseable and check each string
• this helper is likely going to introduce some overhead, we should keep the runtime performance implication in mind
  • for example, it should return early if { and } are not found

[arizedatngo]

related to #2457