#33666 [Bug]: Responses API previous_response_id session reconstruction runs an unbounded SELECT * over LiteLLM_SpendLogs (query-engine OOM)
### What happened?
On a proxy serving `/v1/responses` traffic, the Prisma **query-engine** process grows to **12–16 GB RSS** (≈100% anonymous memory) and fluctuates with load, pushing pods past their memory limit / into OOM.
**Root cause:** `ResponsesSessionHandler.get_all_spend_logs_for_previous_response_id` (`litellm/responses/litellm_completion_transformation/session_handler.py`) reconstructs a session by running an **unbounded** query:
```sql SELECT * FROM "LiteLLM_SpendLogs" WHERE session_id IN (SELECT session_id FROM matching_session) ORDER BY "endTime" ASC; ```
- No `LIMIT`, and `SELECT *` pulls the large blob columns (`messages`, `response`, `proxy_server_request`, `metadata`). - `session_id` comes from `trace_id` (`_get_session_id_for_spend_log`). Any session that maps to many rows makes the query engine **buffer the entire session into memory** before returning it to Python.
This happens for: - a **reused `litellm_trace_id`** across many requests (they collapse into one `session_id`), - a **very long-running conversation** chaining `previous_response_id`, - heavy **tool/MCP fan-out** (multiple spend-log rows per turn).
Because every turn replays the whole prior sess…