Editor freezes on flows with many sessions: /monitor/messages/sessions returns every session with no limit

Bug Description

The editor slows/freezes when opening a chat flow that has accumulated a large number of chat sessions. Root cause: the session-list fetch (GET /api/v1/monitor/messages/sessions?flow_id=…) has no default limit and no ordering, and the frontend session list (useGetSessionsFromFlowQuery) calls it on every editor/playground open with only flow_id — so the backend returns and the browser renders EVERY session the flow has ever had.

Production impact: a chat/agent flow accumulated ~10,000 sessions (~181 kB of ids, measured 1.3–1.5 s server-side per call). The editor's session list renders all of them on open, degrading the editor. Unlike #15023, this grows with sessions, not messages: any flow used with per-request/per-user session ids (e.g. via API or webhook) accumulates them continuously.

This is the same root cause as #15023 (unbounded message-history fetch, fixed by #15051): that PR bounded /monitor/messages and /monitor/messages/shared but left the sibling /monitor/messages/sessions endpoints unbounded — still the case on release-1.12.4 and main.

Reproduction

Steps to reproduce:

1. Create a chat/agent flow and run it in the playground/chat (or via API/webhook with per-request session ids) until the message table has many DISTINCT session_ids for the flow. (Or: INSERT message rows across thousands of distinct session_ids for the flow id.)
2. Open the flow in the editor.
3. Observe: GET /api/v1/monitor/messages/sessions?flow_id= returns EVERY session for the flow — measured 10,690 sessions (~181 kB) with no limit accepted or enforced — and the editor's session list renders all of them, slowing/hanging the editor on open.
4. The payload grows without bound as the flow accumulates more sessions.

Environment: PostgreSQL backend; message table session_id listing with no default LIMIT on the endpoint.

Expected behavior

The session list should be bounded by default (e.g. latest 100 sessions, most recent first — ordered by MAX(timestamp)) and/or the /monitor/messages/sessions endpoint should enforce a server-side maximum limit, mirroring what #15051 did for the message-history endpoints. A flow with a large number of sessions must not degrade or freeze the editor.

Who can help?

@andifilhohub @AhsanAkhlaq @italojohnny

Operating System

Ubuntu Linux (Docker image, Kubernetes deployment)

Langflow Version

1.12.4 (release-1.12.4 branch; also reproduced on 1.12.2+)

Python Version

3.12

Screenshot

No response

Flow File

No response