Troubleshooting Trace Association Issues in Arize with Vercel SDK

Michael S. · 2025-12-03 07:45:15.213558+00

Hi there, I've been setting up Arize using the @arizeai/openinference-vercel library and Vercel's ai sdk. My basic debug setup uses generateText and I have the instrumentation successfully sending spans to Arize. The one issue I'm having is that the spans show up only as spans, with no associated "Trace" item. When inspecting the spans I see the message Unable to find the trace associated with this span. Displaying all spans found for trace_id: 89dc4993dbe65b6c00f4b8a51caf598f. I've been looking at the spans that get exported, and I can't see anything obvious missing. I'm curious if this lack of traces in the UI is to be expected with these libs, and if there's anything I can do to my span exports that might get the traces to show up?

Troubleshooting Trace Association Issues in Arize with Vercel SDK | Arize AI Community

Parker S.
·
Hey Michael, are you doing any filtering of the spans using the spanFilter field on the OpenINferenceSpanProcessor ?
Michael S.
·
I am, and it just occurred to me that maybe I need to send a root span in addition to the OI spans?
Michael S.
·
something like return !span.parentSpanId?
Parker S.
·
Yeah, that's probably what's happening! Although, the warning you're seeing in Arize, I believe, is just a warning an dhsould not impact you
Parker S.
·
but likely the root spans are getting filtered out since most of the vercel stuff is nested under a whole bunch of "non-generative" spans
Parker S.
·
something like return !span.parentSpanId?
Yeah something like this should work, you can compose a custom filter with our isOpenInferenceSpan filter to ensure you get root spans and openinference spans
Michael S.
·
Though, would that cause issues if there are gaps between the root span and the OI span?
Parker S.
·
It depends on what you're looking to do. But if all you care about is "generative" spans they should be safe to omit, as they won't necessarily contain things like token counts and latency
Michael S.
·
Going to give it a shot. I realize the non-generative spans aren't useful in Arize, but we're working on this integration for clients and want to be sure they don't think something is broken or missing.
Parker S.
·
Gotcha, in that case yeah I would just remove the filter and send everything in. You should be able to use the filters in arize to view just generative spans etc. If you find it to be too cluttered you can always start applying the filter again!
Parker S.
·
The warning is a bit jarring but I don't believe it should affect anything
Michael S.
·
Unfortunately we might be leaking non-client instrumentation if we sent everything. The many pains of OTEL.
Michael S.
·
Will report back on where I end up. Thanks for the quick reply!
Parker S.
·
No problem, on the point of leaking we do have data masking in progress for our JS/TS instrumentations, not sure if that's what you meant but is something we've begun work on!
Michael S.
·
I mean really everything that has decided to glom onto OTEL — Sentry attributes, HTTP and AWS instrumentation, a lot of noise and stuff we just don't want to even consider a customer seeing... The majority of our OTEL spans are being generated to observe our services for internal use only, and the AI tracing is just a discrete subset we'd like to export to Arize. In the end I suspect we'll be using a distinct TraceProvider for the generative traces, then hopefully it's as simple as sending everything.

26 comments