Preventing Non-JSON Data in Phoenix Traces

Andrei L. · 2025-12-23T12:47:02.000Z

Hi all. Some users push in to phoenix traces not json, as result, in search I have crush application. What should I do, to prevent it?

6 comments

· Sorted by Oldest

RunLLM
APP
·
·
Phoenix expects trace data to be valid JSON; if non-JSON or invalid JSON is pushed, it can cause UI crashes or errors during search and visualization. To prevent this, ensure all trace data is properly serialized to JSON before sending it to Phoenix. If your application outputs data types like NaN or custom objects, preprocess them to convert NaN to null and ensure all objects are JSON-serializable before storage or export—otherwise, Phoenix may store invalid JSON and downstream parsing will fail, leading to crashes in the UI or errors like "Unexpected token" or "Unexpected end of JSON input" during search or load operations. See <https://github.com/Arize-ai/phoenix/issues/8975|this issue for details and mitigation steps>. Would you like more detail on how to implement these checks or handle specific data types? Sources: - <https://github.com/Arize-ai/phoenix/issues/8975|https://github.com/Arize-ai/phoenix/issues/8975>
💡 Hint: Mention RunLLM in the thread for followups.
Andrei L.
·
·
RunLLM It not a NaN, Someowne push HTML, not JSON
RunLLM
APP
·
·
It seems likely that if someone pushes HTML (or XML) instead of JSON to Phoenix, the backend or UI will attempt to parse it as JSON, resulting in errors like "Unexpected token '<', ... is not valid JSON" and causing the application to crash or display error screens. Phoenix does not currently sanitize or validate incoming trace payloads to ensure they are JSON before storage or processing, so invalid formats can break search and visualization features. See <https://github.com/Arize-ai/phoenix/issues/9208|this issue> and <https://github.com/Arize-ai/phoenix/issues/4091|this one> for examples. To prevent this, you should validate all data as JSON before sending it to Phoenix. If you control the ingestion pipeline, add a check to reject or log any non-JSON payloads before they reach Phoenix. There is no built-in Phoenix-side setting to automatically reject non-JSON traces as of now. Would you like more detail on how to implement such validation in your pipeline? Sources: - <https://github.com/Arize-ai/phoenix/issues/9208|this issue> - <https://github.com/Arize-ai/phoenix/issues/4091|this one>
💡 Hint: Mention RunLLM in the thread for followups.
Andrei L.
·
·
RunLLM All issues, that you put here are closed, May be you wrong ?
RunLLM
APP
·
·
The issues I referenced are closed, but they accurately document the root cause: pushing non-JSON (like HTML/XML) to Phoenix causes parsing errors and UI crashes, as Phoenix expects valid JSON input. The fact that the issues are closed does not mean the underlying requirement for valid JSON has changed—there is still no built-in Phoenix-side validation to reject non-JSON payloads before they cause errors <https://github.com/Arize-ai/phoenix/issues/4091|[source>, <https://github.com/Arize-ai/phoenix/issues/9208|source>]. If you need to prevent these errors, you must validate data as JSON before sending it to Phoenix, since the platform itself does not currently enforce this at the API boundary. Would you like more detail on how to add such validation? Sources: - <https://github.com/Arize-ai/phoenix/issues/4091|https://github.com/Arize-ai/phoenix/issues/4091> - <https://github.com/Arize-ai/phoenix/issues/9208|https://github.com/Arize-ai/phoenix/issues/9208>
💡 Hint: Mention RunLLM in the thread for followups.
Xander S.
·
·
Hey Andrei L., that error screen you show may be due to any number of issues. Can you describe what URL you are attempting to access or what action you are taking in the UI when you see it?

RunLLM
APP
·
·
Phoenix expects trace data to be valid JSON; if non-JSON or invalid JSON is pushed, it can cause UI crashes or errors during search and visualization. To prevent this, ensure all trace data is properly serialized to JSON before sending it to Phoenix. If your application outputs data types like NaN or custom objects, preprocess them to convert NaN to null and ensure all objects are JSON-serializable before storage or export—otherwise, Phoenix may store invalid JSON and downstream parsing will fail, leading to crashes in the UI or errors like "Unexpected token" or "Unexpected end of JSON input" during search or load operations. See <https://github.com/Arize-ai/phoenix/issues/8975|this issue for details and mitigation steps>. Would you like more detail on how to implement these checks or handle specific data types? Sources: - <https://github.com/Arize-ai/phoenix/issues/8975|https://github.com/Arize-ai/phoenix/issues/8975>
💡 Hint: Mention RunLLM in the thread for followups.
Andrei L.
·
·
RunLLM It not a NaN, Someowne push HTML, not JSON
RunLLM
APP
·
·
It seems likely that if someone pushes HTML (or XML) instead of JSON to Phoenix, the backend or UI will attempt to parse it as JSON, resulting in errors like "Unexpected token '<', ... is not valid JSON" and causing the application to crash or display error screens. Phoenix does not currently sanitize or validate incoming trace payloads to ensure they are JSON before storage or processing, so invalid formats can break search and visualization features. See <https://github.com/Arize-ai/phoenix/issues/9208|this issue> and <https://github.com/Arize-ai/phoenix/issues/4091|this one> for examples. To prevent this, you should validate all data as JSON before sending it to Phoenix. If you control the ingestion pipeline, add a check to reject or log any non-JSON payloads before they reach Phoenix. There is no built-in Phoenix-side setting to automatically reject non-JSON traces as of now. Would you like more detail on how to implement such validation in your pipeline? Sources: - <https://github.com/Arize-ai/phoenix/issues/9208|this issue> - <https://github.com/Arize-ai/phoenix/issues/4091|this one>
💡 Hint: Mention RunLLM in the thread for followups.
Andrei L.
·
·
RunLLM All issues, that you put here are closed, May be you wrong ?
RunLLM
APP
·
·
The issues I referenced are closed, but they accurately document the root cause: pushing non-JSON (like HTML/XML) to Phoenix causes parsing errors and UI crashes, as Phoenix expects valid JSON input. The fact that the issues are closed does not mean the underlying requirement for valid JSON has changed—there is still no built-in Phoenix-side validation to reject non-JSON payloads before they cause errors <https://github.com/Arize-ai/phoenix/issues/4091|[source>, <https://github.com/Arize-ai/phoenix/issues/9208|source>]. If you need to prevent these errors, you must validate data as JSON before sending it to Phoenix, since the platform itself does not currently enforce this at the API boundary. Would you like more detail on how to add such validation? Sources: - <https://github.com/Arize-ai/phoenix/issues/4091|https://github.com/Arize-ai/phoenix/issues/4091> - <https://github.com/Arize-ai/phoenix/issues/9208|https://github.com/Arize-ai/phoenix/issues/9208>
💡 Hint: Mention RunLLM in the thread for followups.
Xander S.
·
·
Hey Andrei L., that error screen you show may be due to any number of issues. Can you describe what URL you are attempting to access or what action you are taking in the UI when you see it?