Session Behavior in Phoenix: Unique Session IDs Across Projects

·Oct 30, 2025 03:39 PM·

Hello! I've been struggling with this unexpected (for me) behavior of sessions. Phoenix likely treats session_id as a globally unique identifier across all projects. When I send: - Request 1: project_name="test-session-level-0", session_id="session-0" → Creates session "session-0" under "test-session-level-0" - Request 2: project_name="test-session-level-1", session_id="session-0" → Finds existing session "session-0" and adds to it (inside the project of the request 1) The trace goes to the correct project, but the session grouping happens globally based on session_id. Anyone can help me here? is this the way it's designed to work?

23 comments

· Sorted by Oldest

RunLLM
APP
·
·
Yes, this is by design: Phoenix treats session_id as globally unique, so if you use the same session_id across different projects, the session will be associated with the project where it was first created. Subsequent traces with the same session_id, even if logged to a different project, will be grouped under the original project’s session, not the new one. This behavior is confirmed in the Phoenix codebase and integration tests, which show that session_id is not namespaced per project, but is a global identifier for session grouping and lookup across all projects (<https://github.com/Arize-ai/phoenix/blob/main/tests/integration/project_sessions/test_project_sessions.py|test_project_sessions.py>, <https://github.com/Arize-ai/phoenix/blob/main/src/phoenix/db/insertion/span.py|span.py>). If you want sessions to be project-specific, you must ensure session_id values are unique per project (e.g., by prefixing with the project name). Would you like more detail or code examples on how to handle this? Sources: - <https://github.com/Arize-ai/phoenix/blob/main/tests/integration/project_sessions/test_project_sessions.py|test_project_sessions.py> - <https://github.com/Arize-ai/phoenix/blob/main/src/phoenix/db/insertion/span.py|span.py>
💡 Hint: Mention RunLLM in the thread for followups.
Xander S.
·
·
The trace goes to the correct project, but the session grouping happens globally based on session_id.
Hey Brais M., what session grouping are you referring to? Are you referring to the Sessions tab? Maybe you could send a screenshot.
Brais M.
·
·
Yes, Sessions tab is what I meant, I attached screenshot of what's happening: Request 1: project_name="test-session-level-0", session_id="session-0" → Creates session "session-0"
Brais M.
·
·
Then I send the second request with: Request 2: project_name="test-session-level-1", session_id="session-0" → Finds existing session "session-0" and adds to it As you can see, no sessions created under the project of the "request 2"
Brais M.
·
·
Because the traces of the request 2 are correctly stored under the "test-session-level-1" but the messages of the "session-0" went under the first project
Brais M.
·
·
🔒[private user] If you need more info just tell me
Xander S.
·
·
Can you show me the code?
Xander S.
·
·
After sending the second request, do you see your traces from the second request in the session in the first project?
👀1
Brais M.
·
·
Exactly that
Brais M.
·
·
It's a FastAPI application where I had to use ContextVar to redirect the traces to the project_name specified in the client request, using autotracing with Langgraph and wraping the ReadeableSpan with a ProjectRoutingSpanWrapper to set the Resource with the "scope request" project name
Brais M.
·
·
So it's difficult to share with you the implementation sorry
Xander
External
·
·
No worries. What makes you want to separate the traces for a single session into distinct projects?
Xander S.
·
·
We have an assumption in our data model that a session belongs to exactly one project, which is the project associated with the first trace of the session that Phoenix receives. We assumed when building this feature that session IDs would contain a random element to them (so collisions are unlikely) and that users would typically send the traces from the same session to a single project. https://github.com/Arize-ai/phoenix/blob/main/src/phoenix/db/README.md#core-tracing--projects
Brais M.
·
·
What makes you want to separate the traces for a single session into distinct projects? -> This is what I don't want to, what I try to avoid
Brais M.
·
·
I understand your point, but even collisions are unlikely it could happen if the session_ids are not randomly generated...

RunLLM
APP
·
·
Yes, this is by design: Phoenix treats session_id as globally unique, so if you use the same session_id across different projects, the session will be associated with the project where it was first created. Subsequent traces with the same session_id, even if logged to a different project, will be grouped under the original project’s session, not the new one. This behavior is confirmed in the Phoenix codebase and integration tests, which show that session_id is not namespaced per project, but is a global identifier for session grouping and lookup across all projects (<https://github.com/Arize-ai/phoenix/blob/main/tests/integration/project_sessions/test_project_sessions.py|test_project_sessions.py>, <https://github.com/Arize-ai/phoenix/blob/main/src/phoenix/db/insertion/span.py|span.py>). If you want sessions to be project-specific, you must ensure session_id values are unique per project (e.g., by prefixing with the project name). Would you like more detail or code examples on how to handle this? Sources: - <https://github.com/Arize-ai/phoenix/blob/main/tests/integration/project_sessions/test_project_sessions.py|test_project_sessions.py> - <https://github.com/Arize-ai/phoenix/blob/main/src/phoenix/db/insertion/span.py|span.py>
💡 Hint: Mention RunLLM in the thread for followups.
Xander S.
·
·
The trace goes to the correct project, but the session grouping happens globally based on session_id.
Hey Brais M., what session grouping are you referring to? Are you referring to the Sessions tab? Maybe you could send a screenshot.
Brais M.
·
·
Yes, Sessions tab is what I meant, I attached screenshot of what's happening: Request 1: project_name="test-session-level-0", session_id="session-0" → Creates session "session-0"
Brais M.
·
·
Then I send the second request with: Request 2: project_name="test-session-level-1", session_id="session-0" → Finds existing session "session-0" and adds to it As you can see, no sessions created under the project of the "request 2"
Brais M.
·
·
Because the traces of the request 2 are correctly stored under the "test-session-level-1" but the messages of the "session-0" went under the first project
Brais M.
·
·
🔒[private user] If you need more info just tell me
Xander S.
·
·
Can you show me the code?
Xander S.
·
·
After sending the second request, do you see your traces from the second request in the session in the first project?
👀1
Brais M.
·
·
Exactly that
Brais M.
·
·
It's a FastAPI application where I had to use ContextVar to redirect the traces to the project_name specified in the client request, using autotracing with Langgraph and wraping the ReadeableSpan with a ProjectRoutingSpanWrapper to set the Resource with the "scope request" project name
Brais M.
·
·
So it's difficult to share with you the implementation sorry
Xander
External
·
·
No worries. What makes you want to separate the traces for a single session into distinct projects?
Xander S.
·
·
We have an assumption in our data model that a session belongs to exactly one project, which is the project associated with the first trace of the session that Phoenix receives. We assumed when building this feature that session IDs would contain a random element to them (so collisions are unlikely) and that users would typically send the traces from the same session to a single project. https://github.com/Arize-ai/phoenix/blob/main/src/phoenix/db/README.md#core-tracing--projects
Brais M.
·
·
What makes you want to separate the traces for a single session into distinct projects? -> This is what I don't want to, what I try to avoid
Brais M.
·
·
I understand your point, but even collisions are unlikely it could happen if the session_ids are not randomly generated...