BackendSpanExporter: one metadata or custom span value that isn't JSON serializable drops the whole export batch, including unrelated traces

[Om-singhaI]

Describe the bug

BackendSpanExporter posts a whole batch of traces and spans in one request. If any one item in that batch has a value json can't encode, the request body can't be built, export() raises, and BatchTraceProcessor drops the entire batch. So one bad value in one run's trace_metadata also throws away every other trace and span that happened to be queued with it, including runs that had nothing wrong with them.

Things that trigger it: a uuid.UUID or datetime in RunConfig(trace_metadata=...), a datetime in custom_span(data=...), or a NaN or inf float (httpx2 encodes with allow_nan=False). It happens on the default OpenAI ingest endpoint and on custom endpoints.

Debug information

• Agents SDK version: 0.22.2 (also main at fbd2dbc)
• Python version: 3.14.3
• Operating system: macOS
• Model and model provider: none needed, the repro uses ScriptedModel
• Does the issue reproduce with the latest Agents SDK release? Yes
• Does the issue occur consistently or intermittently? Consistently

ERROR [non-fatal] Tracing exporter failed; dropping batch of 8 items
items received: 0 []

Calling the exporter directly shows the cause:

exporter.export([trace("x", metadata={"request_id": uuid.uuid4()})])
TypeError: Object of type UUID is not JSON serializable

Repro steps

The repro doesn't touch the network. httpx2.MockTransport stands in for the ingest endpoint.

import asyncio, json, uuid, logging
import httpx2
from agents import Agent, Runner, RunConfig
from agents.testing.model import ScriptedModel, assistant_message
from agents.tracing import set_trace_processors
from agents.tracing.processors import BackendSpanExporter, BatchTraceProcessor

logging.basicConfig(level=logging.ERROR, format="%(levelname)s %(message)s")
received = []

def handler(request):
    received.extend(json.loads(request.content)["data"])
    return httpx2.Response(200)

exporter = BackendSpanExporter(api_key="sk-fake")  # default OpenAI ingest endpoint
exporter._client = httpx2.Client(transport=httpx2.MockTransport(handler))
processor = BatchTraceProcessor(exporter, schedule_delay=3600)
set_trace_processors([processor])

async def main():
    agent = Agent(name="assistant", model=ScriptedModel([[assistant_message("hi")], [assistant_message("hi")]]))
    await Runner.run(agent, "hello", run_config=RunConfig(workflow_name="run_A"))  # nothing wrong with this run
    await Runner.run(agent, "hello", run_config=RunConfig(
        workflow_name="run_B", trace_metadata={"request_id": uuid.uuid4()}))

asyncio.run(main())
processor.force_flush()
print("items received:", len(received), [d.get("workflow_name") for d in received if d.get("object") == "trace"])

Expected behavior

run_A's trace and spans get exported no matter what's in run_B's metadata. At most, the value that can't be encoded gets dropped from run_B, and run_B's trace and spans still arrive.

[seratch]

Thanks for the clear report. The batch-loss behavior is supported by the current code: serialization fails after the processor has dequeued the records, so unrelated traces in that batch are lost.

We should address this with a bounded exporter fix that preserves valid neighboring records and retains trace/span identity when omitting unencodable metadata. Applications should still convert values such as UUIDs and datetimes explicitly when those values need to appear in traces. This does not require a general-purpose Python object serializer.

[socksninja]

This looks like a particularly useful reliability regression because the failure crosses a batch boundary: one malformed observation can make unrelated healthy traces disappear.

A narrow regression that would make the guarantee machine-checkable:

1. enqueue two runs in the same batch, A (fully JSON-serializable) and B (one intentionally non-serializable metadata value);
2. force the batch flush through the mock transport;
3. assert A's trace/spans are still received;
4. assert B is either received with only the offending field omitted/redacted, or rejected in isolation;
5. assert the exporter reports which item was unencodable rather than only "dropping batch";
6. repeat with 3+ items so the test proves this is per-item isolation, not an accidental two-item special case.

For evidence, I'd record the pre-flush item IDs, the mock receiver's received IDs, and a canonical hash of each received item. That gives a simple invariant:

valid input item id -> received item id OR explicitly rejected item id

rather than using the exporter success/exception as the source of truth.

That distinction matters for reliability: a successful export() call is not sufficient evidence that every queued trace became observable.

[socksninja]

This is a clean evidence-boundary failure: one malformed trace item causes the exporter to drop unrelated healthy traces in the same batch. The useful audit question is not merely whether export() raises, but whether each queued trace has an independently checkable disposition.

SABLE can run a bounded reproduction with good/bad/good items, capture the pre-flush IDs, receiver IDs, batch/error state, and fresh-read the resulting evidence to distinguish preserved, rejected, and silently lost records.

US$99 fixed founding audit, customer-paid to SABLE. No production credentials or OpenAI adoption required.

Payment: https://www.paypal.com/ncp/payment/2URELJ9NE4ZBN

[socksninja]

@Om-singhaI — this is now a very small, machine-checkable external reliability audit rather than another exporter design discussion.

US$99 fixed audit: good/bad/good traces in one batch → independent mock receiver readback → per-item received/rejected/lost disposition → canonical hashes → concise evidence report.

The key invariant is queued item → received OR explicitly rejected; exporter success alone is not treated as proof.

No production credentials or OpenAI adoption required.

Customer → SABLE: https://www.paypal.com/ncp/payment/2URELJ9NE4ZBN

Reply YES and I’ll lock the test boundary.