You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
retriever span in llama-index 0.9.5 is now put under a new trace and new callback manager (potentially fragmenting the parent-child graph of the spans)
#1796
Closed
RogerHYang opened this issue
Nov 21, 2023
· 0 comments
In llama-index 0.9.5, retriever starts a new trace and new callback manager (of BaseRetriever), instead of just a new span under the same trace and same callback manager of its parent span.
In general, there are too many ways a different callback manager can specified for each portion of a trace. This can lead to the fragmentation of the trace map (i.e. the parent-child graph of the spans), because each callback manager keeps and updates a separate trace map. When phoenix receive the final trace map, it only come from one callback manager, and the trace map may not be a complete version containing all the spans.
Alternatively, we can construct our own trace map using the parent_id argument in on_event_start, but that has the downside of a potential memory leak: we may not know when the trace map can be destroyed.
The text was updated successfully, but these errors were encountered:
RogerHYang
changed the title
[BUG] retriever span in llama-index 0.9.5 is now put under a new trace that doesn't inherit the Phoenix handler (so CBEventType.RETRIEVE doesn't get to Phoenix)
[BUG] retriever span in llama-index 0.9.5 is now put under a new trace (instead of under the same trace as its parent span)
Nov 21, 2023
RogerHYang
changed the title
[BUG] retriever span in llama-index 0.9.5 is now put under a new trace (instead of under the same trace as its parent span)
[BUG] retriever span in llama-index 0.9.5 is now put under a new trace and new callback manager (instead of under the same trace and same callback manager as its parent span)
Nov 21, 2023
RogerHYang
changed the title
[BUG] retriever span in llama-index 0.9.5 is now put under a new trace and new callback manager (instead of under the same trace and same callback manager as its parent span)
retriever span in llama-index 0.9.5 is now put under a new trace and new callback manager (instead of under the same trace and same callback manager as its parent span)
Nov 21, 2023
RogerHYang
changed the title
retriever span in llama-index 0.9.5 is now put under a new trace and new callback manager (instead of under the same trace and same callback manager as its parent span)
retriever span in llama-index 0.9.5 is now put under a new trace and new callback manager (potentially fragmenting the trace map)
Nov 21, 2023
RogerHYang
changed the title
retriever span in llama-index 0.9.5 is now put under a new trace and new callback manager (potentially fragmenting the trace map)
retriever span in llama-index 0.9.5 is now put under a new trace and new callback manager (potentially fragmenting the parent-child graph of the spans)
Nov 21, 2023
dosubotbot
added
the
stale
Issue has not had recent activity or appears to be solved. Stale issues will be automatically closed
label
Jun 8, 2024
In llama-index 0.9.5, retriever starts a new trace and new callback manager (of
BaseRetriever
), instead of just a new span under the same trace and same callback manager of its parent span.In general, there are too many ways a different callback manager can specified for each portion of a trace. This can lead to the fragmentation of the trace map (i.e. the parent-child graph of the spans), because each callback manager keeps and updates a separate trace map. When phoenix receive the final trace map, it only come from one callback manager, and the trace map may not be a complete version containing all the spans.
Alternatively, we can construct our own trace map using the
parent_id
argument inon_event_start
, but that has the downside of a potential memory leak: we may not know when the trace map can be destroyed.The text was updated successfully, but these errors were encountered: