The /v1/responses endpoint generated a fresh session_id (uuid4) for
every request, even when previous_response_id was provided. This caused
each chained response to appear as a separate session in the web
dashboard despite being part of the same conversation.
Fix: store session_id alongside the response in ResponseStore. When
previous_response_id resolves, reuse the stored session_id so the
entire conversation maps to a single session. Falls back to a fresh
UUID for the first request or when chaining from older responses that
predate this field.
Also handles the edge case where conversation_history is provided
explicitly alongside previous_response_id — the session_id is still
retrieved from the stored response even though the explicit history
takes precedence over the stored one.
Reported by @thelumiereguy.
Teknium
f71d6841ed