Hi! Why does the package arize-phoenix-client not have an implementation of log_traces? The problem with this is that we are changing our implementation to self host with the arize-phoenix-client package to avoid overhead and because log_traces is not implemented we are using instead log_spans, but since the log_spans function wasn't implemented until arize-phoenix 10.12.0, this makes so it is no longer backwards compatible with our servers that have a previous version deployed.
The arize-phoenix-client package does not implement log_traces; instead, it provides log_spans, which was added in version 10.12.0. This change means that if your server is running a version older than 10.12.0, log_spans will not work, and there is no log_traces method available in the client for backward compatibility. This limitation is acknowledged in the changelogs and related discussions, and there is no official workaround for using log_traces with the thin client on older server versions鈥攗sers must either upgrade their server or use the full arize-phoenix package for legacy support (changelog, client changelog, log_spans PR).Would you like more detail on migration strategies or compatibility options?Sources:
- Phoenix main changelog
- Phoenix client changelog
- log_spans PR
馃挕聽Hint: Mention RunLLM in the thread for followups.
Good morning Alejandro E. - a bit of rationale here. log_traces used to use PyArrow streaming under the hood which causes all sorts of schema issues around metadata. Because of this we moved transport to be entirely JSON based to support non-homogenous payloads. The endpoints that back log_traces still exist and you could certainly lift those methods to accomplish the same thing. Mainly curious, is there anything preventing you from upgrading to the latest phoenix version? It would be the simplest solution here.
