Description
Currently, every time the frontend polls /api/state (every 4 seconds), the MonitoringService fetches raw database records for workflows, tasks, and attempts, and then runs heavy Python loops (e.g., _derive_execution_status, _task_execution_projection) to calculate the UI snapshot on the fly. As the historical database grows, this O(N) calculation will severely degrade performance.
Proposal
We need to decouple the state derivation logic from the HTTP request cycle to prevent the backend from bottlenecking under load.
Acceptance Criteria
- Implement an in-memory caching layer (with a TTL of 1-2 seconds) for the
/api/state response.
- Alternatively, push the derivation logic down into the SQLite layer using triggers or Materialized Views, so the API only executes a single, highly-optimized SQL read.
- Ensure the
/api/state endpoint responds in under 50ms regardless of the historical database size.
Description
Currently, every time the frontend polls
/api/state(every 4 seconds), theMonitoringServicefetches raw database records for workflows, tasks, and attempts, and then runs heavy Python loops (e.g.,_derive_execution_status,_task_execution_projection) to calculate the UI snapshot on the fly. As the historical database grows, this O(N) calculation will severely degrade performance.Proposal
We need to decouple the state derivation logic from the HTTP request cycle to prevent the backend from bottlenecking under load.
Acceptance Criteria
/api/stateresponse./api/stateendpoint responds in under 50ms regardless of the historical database size.