RunLLM

This error means Phoenix's database migration is incomplete or corrupted ("dirty state"). The recommended fix is to use the Alembic CLI from the src/phoenix/db directory to revert partial migrations and run alembic stamp to reset the migration state, then restart Phoenix. If you can't find src/phoenix/db (e.g., when running from a container), you may need to clone the Phoenix repo locally to access it, or run Alembic from the installed package path. This issue often occurs after an upgrade, downgrade, or if the database is shared or manually altered. If you can't afford to lose data, manual intervention is required; otherwise, deleting the database and starting fresh is the simplest fix. Using a dedicated, fresh database for Phoenix is highly recommended to avoid such conflicts.If you need to run Alembic manually, see the discussion and instructions in these sources. If you need step-by-step guidance for your specific setup (Kubernetes, Docker, etc.), let me know.Sources: - Phoenix migration troubleshooting and Alembic usage - Slack support thread: database dirty state and manual migration

Yes, you can filter spans directly at query time using Phoenix's query DSL, which is more efficient than fetching all data and filtering locally. Use the SpanQuery class to specify filters such as trace_id in [...], attributes['session.id'] == ..., or any other attribute, and pass this query to client.query_spans() or client.spans.get_spans_dataframe() with your filter condition. This reduces data transfer and speeds up retrieval.Example for filtering by a list of trace IDs: LBKSfrom phoenix.trace.dsl import SpanQuery query = SpanQuery().where("trace_id in ['id1', 'id2', 'id3']") spans_df = client.query_spans(query, project_name="agentic_service_project")LBKSYou can also filter by attributes, e.g., attributes['session.id'] == 'your_session_id'. This approach avoids loading all data and lets you control the result size efficiently. Would you like more detail or examples for other filters?Sources: - Extract Data from Spans - SpanQuery DSL - GitHub Issue: Filter by Span ID

If you can still retrieve traces and annotations via the API but see 0 traces in the Phoenix Cloud UI, this is likely due to the default time filter in the UI (often set to the last 15 minutes), not data loss. Adjust the time range filter in the UI to a broader window (e.g., "All time" or a custom range covering when you logged the traces) and your traces and annotations should reappear. This is a known UI behavior and not an indication that your data is missing or deleted—your data remains accessible via API and is still present in the backend according to GitHub issue 6016.If changing the time filter does not resolve the issue, try clearing your browser cache or refreshing the page, as UI state or caching issues can sometimes prevent data from displaying correctly. If the problem persists after these steps, it may be a UI bug, and you should report it to the Phoenix team for further investigation as suggested in GitHub issue 6016.Would you like more detail on troubleshooting or API usage?Sources: - GitHub issue 6016

It could be possible that Phoenix itself does not make any explicit claims of being GDPR or SOC 2 compliant in the available documentation. Though I'm not entirely certain, it might be that compliance depends on how you self-host and configure Phoenix, as there is no formal assessment or certification for GDPR or SOC 2 mentioned for the open-source version. For enterprise needs like compliance, the Arize platform (the company behind Phoenix) may offer additional guarantees, but this is not detailed for Phoenix OSS itself according to the sources reviewed.Would you like more detail on how Phoenix handles data privacy or how Arize AX addresses compliance requirements?Sources: - https://arize-ai.slack.com/archives/C04R3GXC8HK/p1720623789.861679 Note: I wasn’t able to find highly relevant data sources, but above are a few potentially relevant links.

If you tell me the right answer to this question, I'll make sure I don't make the same mistake twice!

This is a known Phoenix UI issue: when a dataset is newly created and contains zero examples or versions, actions like adding examples or launching the playground may be disabled or cause errors. The recommended fix is to add at least one example during creation, or refresh the page if the UI becomes unresponsive. Upgrading to the latest Phoenix version may also help, as improvements have been released to address this behavior. If you still encounter the issue, ensure you are not trying to interact with the dataset before any examples exist, and look for tooltips or UI messages explaining the requirement. For more details and workarounds, see the related GitHub issues and discussions. Would you like more detail or troubleshooting steps?Sources: - GitHub Issue: cannot create new dataset from the the + next to the dataset picker - https://github.com/Arize-ai/phoenix/issues/10104 - GitHub Issue: Cannot add to a empty dataset

It seems likely that filtering traces by a specific feedback label (e.g., feedback.label == "thumbs-up") may not work because the correct way to filter by annotation label is to use the evaluation name as an indexer on the special keyword evals, like so: evals['feedback'].label == 'thumbs-up'. The feedback column itself is an aggregation and not directly filterable in this way in the query DSL or UI filter bar.For example, to filter for spans or traces with a "thumbs-up" feedback annotation, use: LBKSquery = SpanQuery().where("evals['feedback'].label == 'thumbs-up'")LBKSThis approach is supported in both the Python API and the Phoenix UI filter bar, as long as the evaluation/annotation is named "feedback" and the label is "thumbs-up" as per your configuration. Would you like more detail or examples for your specific setup?Sources: - How to filter by evaluation results

There is currently no supported way to run Phoenix as a pure OTLP "collector only" without the UI; the UI and GraphQL API are always enabled when running phoenix serve. Disabling just the UI or GraphQL polling is not possible via configuration, though authentication and access control features are being developed to help secure deployments. The frequent GraphQL polling is due to the frontend checking for new data, and cannot be tuned or disabled independently at this time. This limitation is acknowledged by the Phoenix team and tracked as a feature request for future releases.Would you like more detail on possible workarounds or updates on this feature?Sources: - Slack discussion: No way to disable UI or GraphQL API only

Yes, for short-lived jobs (like AWS Lambda) using batch mode with phoenix.otel, you should call tracer_provider.force_flush() before the process exits to ensure all spans are exported. This is the recommended approach, as batch processors buffer spans and may not export them immediately unless flushed manually in short-lived environments. There is no better built-in alternative documented for this scenario—manual flushing is necessary to avoid losing traces on process exit.For reference, see the Spring AI Java example and LangChain4j Java example, which both explicitly call forceFlush() on the tracer provider before shutdown to guarantee all traces are sent. The same principle applies to Python and other languages using Phoenix with OpenTelemetry batch span processors.Would you like more detail or a code example?Sources: - Spring AI Java example - LangChain4j Java example

It seems likely that Phoenix can be scaled both vertically (by increasing CPU/memory) and horizontally (by running multiple Phoenix containers behind a single PostgreSQL database). Phoenix is stateless, so you can add more instances as needed to handle increased load. There is no explicit mention of a "web_concurrency" parameter, but scaling out by adding more containers is supported, and you should monitor memory and database usage to adjust resources accordingly. For production, enabling batch processing and using gRPC transport is recommended for efficiency. You can scale up by increasing resources (CPU, RAM) per container, and scale out by deploying multiple Phoenix containers connected to the same Postgres instance. Regularly monitor memory and disk usage, and enable database backups for reliability. There is no documentation on a specific "web_concurrency" setting, so concurrency is managed by the number of running containers and the resources allocated to each one, not by a single config variable for worker count or concurrency level. Would you like more detail on deployment or resource tuning?Sources: - Production Guide | Arize Phoenix - Phoenix container scaling discussion (Slack)