fix(playground): optimize canvas performance by limiting chat history fetch

[gmrnlg1971]

Fixes #13460

Description

Resolves canvas performance degradation after repeated Playground runs by limiting the number of messages fetched initially and only enabling the fetch when the playground is visible.

Changes

• Backend: Added limit and order query parameters to GET /monitor/messages to allow retrieving the latest N messages efficiently.
• Frontend: Updated useChatHistory to conditionally enable the message fetch only when visibleSession is true, preventing unnecessary background fetches on canvas changes.

Summary by CodeRabbit

Release Notes

• New Features
  • Messages endpoint now supports controlling sort direction (ascending or descending)
  • Messages endpoint now supports limiting the number of results returned

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: fa60dcc2-1b9f-4a76-aadc-e75da54a1f0f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Walkthrough

The pull request extends the message history endpoint with pagination and ordering controls, while updating the frontend to conditionally fetch messages only when the session is visible and to pass the new pagination parameters.

Changes

Message History Pagination and Conditional Fetching

Layer / File(s)	Summary
Backend ordering and limit parameters src/backend/base/langflow/api/v1/monitor.py	get_messages adds order (default "ASC") and limit (default None) query parameters; ordering dynamically applies ascending or descending direction, and the query conditionally applies .limit() when limit is provided.
Frontend conditional query with pagination parameters src/frontend/src/components/core/playgroundComponent/chat-view/chat-messages/hooks/use-chat-history.ts	useChatHistory now nests limit and order under params when calling useGetMessagesQuery, and enables the query only when visibleSession is truthy to avoid fetching when the session is not active.

---

🎯 2 (Simple) | ⏱️ ~12 minutes

---

Important

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

❌ Failed checks (1 error, 2 warnings, 1 inconclusive)

Check name	Status	Explanation	Resolution
Test Coverage For New Implementations	❌ Error	Backend monitor.py and frontend use-chat-history.ts add limit/order/enabled logic, but repo tests show no new/updated test files covering these behaviors.	Add regression tests: backend for GET /monitor/messages (order_by+order, limit) and frontend for useChatHistory (enabled only when visibleSession, passes params nesting).
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Test Quality And Coverage	⚠️ Warning	No tests validate new /monitor/messages query params (order/limit) or frontend enabled+params behavior; existing backend tests cover auth and generic ordering only, frontend tests cover routing wit...	Add backend tests for GET /monitor/messages with limit and ASC/DESC (and invalid order_by/order/limit error cases), plus frontend tests for useChatHistory gating (enabled: !!visibleSession) and passing limit/order in nested params.
Linked Issues check	❓ Inconclusive	The PR partially implements the proposed fix. Backend adds limit and order parameters as required [#13460], but frontend only gates fetching by visibility and does not yet implement scroll-up pagination or offset support.	Verify whether scroll-up pagination and offset-based loading for older messages are required for this PR or deferred to a follow-up. The linked issue proposes a LoadMoreTrigger component that is not present in these changes.

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: optimizing performance by limiting chat history fetch, which is the core objective of this PR.
Out of Scope Changes check	✅ Passed	All changes are directly related to the performance optimization objectives. The backend endpoint modifications and frontend visibility gating align with issue #13460 requirements.
Test File Naming And Structure	✅ Passed	PR #13647 changes only src/backend/base/langflow/api/v1/monitor.py and src/frontend/.../use-chat-history.ts; no test files added/modified, so naming/structure check not applicable.
Excessive Mock Usage Warning	✅ Passed	GitHub PR #13647 modifies only 2 non-test files (monitor.py and use-chat-history.ts); no test files were changed, so no excessive mock usage to assess.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/backend/base/langflow/api/v1/monitor.py`:
- Around line 229-231: In get_messages validate the three query params at the
API boundary: replace the direct getattr(MessageTable, order_by) use with an
allow-list (e.g., acceptable_fields = {"id","timestamp","user_id",...}) and
return HTTP 400 if order_by is not in that set; validate order by normalizing to
upper() and only accept "ASC" or "DESC" (return HTTP 400 on other values) and
apply the corresponding ascending/descending ordering; validate limit to a safe
integer range (e.g., min 1, max reasonable cap like 1000), return HTTP 400 for
out-of-range or non-positive values, and only call stmt.limit(validated_limit)
with the sanitized value—make these checks in get_messages before building the
SQLAlchemy statement so invalid inputs are rejected at the API boundary.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 1715ebbe-b46d-4e92-a7a8-5d4890265248

📥 Commits

Reviewing files that changed from the base of the PR and between 43d3510 and 8da2dc9.

📒 Files selected for processing (2)

• src/backend/base/langflow/api/v1/monitor.py
• src/frontend/src/components/core/playgroundComponent/chat-view/chat-messages/hooks/use-chat-history.ts

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify there is no existing validation/coverage gap around these params
rg -n -C3 'def get_messages\(|order_by|order:|limit:' src/backend/base/langflow/api/v1/monitor.py
rg -n -C3 'Invalid order_by field|get_messages\(|/messages' src/backend/tests src/backend/base/langflow/tests

Repository: langflow-ai/langflow

Length of output: 50376

---

Validate /monitor/messages query params (order_by, order, limit) at the API boundary.

• In src/backend/base/langflow/api/v1/monitor.py (get_messages, lines 229-267), order_by is used directly in getattr(MessageTable, order_by) with no allow-list (unlike /messages/shared, which rejects invalid fields with HTTP 400).
• order is treated as DESC only when order.upper() == "DESC"; any other value silently becomes ASC.
• limit is applied via stmt.limit(limit) with no bounds, enabling pathological values.

Add an allow-list for order_by, restrict order to ASC|DESC, and enforce min/max (or reasonable caps) for limit, returning 400 on invalid input instead of letting exceptions/expensive queries reach the DB layer.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/backend/base/langflow/api/v1/monitor.py` around lines 229 - 231, In
get_messages validate the three query params at the API boundary: replace the
direct getattr(MessageTable, order_by) use with an allow-list (e.g.,
acceptable_fields = {"id","timestamp","user_id",...}) and return HTTP 400 if
order_by is not in that set; validate order by normalizing to upper() and only
accept "ASC" or "DESC" (return HTTP 400 on other values) and apply the
corresponding ascending/descending ordering; validate limit to a safe integer
range (e.g., min 1, max reasonable cap like 1000), return HTTP 400 for
out-of-range or non-positive values, and only call stmt.limit(validated_limit)
with the sanitized value—make these checks in get_messages before building the
SQLAlchemy statement so invalid inputs are rejected at the API boundary.