Missing pagination on GET /api/workflows causes memory exhaustion / DoS risk on large workspaces #3435
Description
Describe the bug - The GET /api/workflows endpoint currently fetches all workflows for a user or a workspace without any pagination or LIMIT logic applied in the database query.
As workspaces scale up and accumulate thousands of workflows, this forces the database to dump every single row into server memory at once. It risks causing Node.js OOM crashes on the backend, freezing the client's browser when parsing the massive JSON payload, and acts as an unintentional DoS vector for heavy workspaces.
To Reproduce Steps to reproduce the behavior:
1 - Create a workspace with a massively high number of workflows (e.g., via script).
2 - Go to the dashboard/workflow list page.
3 - Check the network tab for the GET /api/workflows request.
4 - See that the backend returns the entire unbounded list of workflows in a single giant payload, and the app stutters or crashes.
Expected behavior The endpoint should implement some form of pagination (either cursor-based or standard offset/limit) so the UI can lazy-load or paginate the workflows in safe chunks (like 50-100 at a time).
Additional context I noticed this while looking at
apps/sim/app/api/workflows/route.ts
around line 70. Both the workspace-specific query and the all-user-workspace queries are entirely unbounded.
im happy to tackle a PR for this if the team has a preference between cursor or offset pagination!