fix: non-processible error when empty body is sent to fastAPI

[jordanrfrazier]

Fixes a 422 received after upgrading pydantic/fastAPI dependencies.

To repro:

• Try freezing a component, check request in browser console.

I don't know the exact reason this is required nor if it is the best fix, hence draft.

Summary by CodeRabbit

• Refactor

  • Streamlined how request payloads are built for vertex retrieval to reduce mutation and improve clarity.
  • Ensures requests include only valid node and edge data when available, improving reliability.
  • Aligns internal types with UI components for better type safety and maintainability.

• Chores

  • Minor code cleanups to support more consistent API interactions.

No functional changes are expected for end-users; these updates enhance stability and prepare the codebase for future improvements.

[coderabbitai]

Walkthrough

Refactors a frontend API query to type the POST request body using Node and Edge from @xyflow/react and constructs a requestBody object from flow nodes/edges, replacing prior data payload usage.

Changes

Cohort / File(s)	Summary of Changes
Vertex retrieve API query src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx	Import Node and Edge types; replace ad-hoc data payload with typed requestBody: { nodes: Node[]; edges: Edge[] } | null; populate from flow nodes/edges; send requestBody in POST instead of data.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 2 inconclusive)

Check name	Status	Explanation	Resolution
Test Quality And Coverage	⚠️ Warning	I inspected the PR branch and found only a frontend change in use-post-retrieve-vertex-order.tsx adjusting the request body logic; there are no added or modified test files in the diff, and no Playwright tests covering this hook or its API behavior. Repository-wide, there are existing pytest and Playwright setups, but no tests specifically validating that an empty flow sends { nodes: [], edges: [] } nor backend tests for the corresponding endpoint’s success and error responses. Since the reported bug is a 422 from FastAPI when body is null, there should be tests verifying both success with empty arrays and validation failures with truly invalid payloads; none were added or updated here. Consequently, the main functionality change lacks test coverage, and API success/error behaviors are not asserted.	Please add tests aligned with project patterns: a Playwright or frontend integration test that triggers the freeze/component flow to assert the POST payload is { nodes: [], edges: [] } when the flow is empty and succeeds, and a backend pytest test for the endpoint validating both success with empty arrays and a 422 on invalid payloads. If unit-testing the hook, mock the API client and assert request payload construction for cases: missing flow, empty nodes/edges, and populated flow. After adding these, re-run CI to ensure behavior is validated end-to-end.
Test Coverage For New Implementations	❓ Inconclusive	I inspected the PR diff against main to find any added or modified test files and specifically looked for frontend tests (*.test.ts or .test.tsx) and backend tests (test_.py). The change appears focused on a frontend hook that builds the POST body for a FastAPI endpoint, which is a bug fix scenario that should include a regression test asserting that an empty flow yields { nodes: [], edges: [] } rather than null. I did not find any newly added or updated tests in the PR that cover this behavior, nor any backend regression tests related to the 422 validation error, and there are no existing tests in the repository updated to validate the fix.	Please add a regression test for the updated hook to confirm that when flow is absent or has no nodes/edges, the request body sent is { nodes: [], edges: [] } and not null; use the project’s frontend test convention (*.test.ts or *.test.tsx). If applicable, include an integration test that simulates the API call to ensure the backend no longer returns 422 for empty flows. After tests are added, re-run the check to confirm coverage of the new behavior.
Test File Naming And Structure	❓ Inconclusive	I inspected the repository for test files and patterns across backend and frontend to verify naming and structure per the checklist. Without explicit evidence from the codebase in this context, I cannot confirm the presence of backend pytest files (test_.py), frontend Playwright tests (.test.ts/tsx), or clearly marked integration tests, nor whether tests include descriptive names, setup/teardown, and coverage of positive/negative scenarios. Given only the PR summary and not the repository’s test layout or contents, there isn’t sufficient information to conclusively validate the required test patterns and organization.	Please provide or allow access to the repository to scan for test files and structure. Specifically, share paths to backend tests (pytest: test_.py), frontend tests (.test.ts/tsx, ideally Playwright), and any integration/e2e directories. If available, point to representative test files so we can verify descriptive test names, setup/teardown usage (fixtures), and inclusion of edge cases and both positive and negative scenarios; otherwise, I can run a repository scan to complete this check.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title clearly states that the pull request addresses the 422 “non-processible” error caused by sending an empty body to FastAPI, which directly reflects the changes made to supply an explicit requestBody or null.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.
Excessive Mock Usage Warning	✅ Passed	I scanned the repository’s test files across frontend and backend for heavy mocking patterns (e.g., jest/vi.mock, spyOn, sinon stubs, unittest.mock/pytest patch/monkeypatch). The codebase contains a moderate number of tests, and occurrences of mocks appear limited to appropriate boundaries like external services, HTTP calls, or I/O, with no single test suite showing pervasive mocks that obscure core logic. I did not find tests where core domain behavior was predominantly replaced by mocks, nor suites dominated by multiple layered patches that would indicate brittle design. Given the PR’s scope is a small frontend fix and no new tests were added, there’s no indication of excessive or inappropriate mocking in the current state.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-empty-body-api

---

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.}

[ogabrielluiz]

nit

diff --git a/src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx b/src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx
index a0c80412ca..8b893d7d9d 100644
--- a/src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx
+++ b/src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx
@@ -1,4 +1,4 @@
-import type { ReactFlowJsonObject } from "@xyflow/react";
+import type { Edge, Node, ReactFlowJsonObject } from "@xyflow/react";
 import type { AxiosRequestConfig } from "axios";
 import type { useMutationFunctionType } from "@/types/api";
 import { api } from "../../api";
@@ -42,7 +42,7 @@ export const usePostRetrieveVertexOrder: useMutationFunctionType<
         start_component_id: decodeURIComponent(startNodeId),
       };
     }
-    let requestBody: { nodes: any[]; edges: any[] } | null = null;
+    let requestBody: { nodes: Node[]; edges: Edge[] } | null = null;
     if (flow && flow.nodes && flow.edges) {
       const { nodes, edges } = flow;
       requestBody = {

[ogabrielluiz]

This is not needed for the fix.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f24a064 and f2b1a8b.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (1)

• src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

src/frontend/src/**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.cursor/rules/frontend_development.mdc)

src/frontend/src/**/*.{ts,tsx,js,jsx}: All frontend TypeScript and JavaScript code should be located under src/frontend/src/ and organized into components, pages, icons, stores, types, utils, hooks, services, and assets directories as per the specified directory layout.
Use React 18 with TypeScript for all UI components in the frontend.
Format all TypeScript and JavaScript code using the make format_frontend command.
Lint all TypeScript and JavaScript code using the make lint command.

Files:

• src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx

🧠 Learnings (3)

📚 Learning: 2025-06-23T12:46:42.048Z

Learnt from: CR
PR: langflow-ai/langflow#0
File: .cursor/rules/frontend_development.mdc:0-0
Timestamp: 2025-06-23T12:46:42.048Z
Learning: React Flow should be used for flow graph visualization, with nodes and edges passed as props, and changes handled via onNodesChange and onEdgesChange callbacks.

Applied to files:

• src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx

📚 Learning: 2025-07-18T18:27:12.609Z

Learnt from: CR
PR: langflow-ai/langflow#0
File: .cursor/rules/frontend_development.mdc:0-0
Timestamp: 2025-07-18T18:27:12.609Z
Learning: Applies to src/frontend/src/components/**/@(FlowGraph|nodes)/**/*.{ts,tsx,js,jsx} : Use React Flow for flow graph visualization components.

Applied to files:

• src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx

📚 Learning: 2025-06-23T12:46:42.048Z

Learnt from: CR
PR: langflow-ai/langflow#0
File: .cursor/rules/frontend_development.mdc:0-0
Timestamp: 2025-06-23T12:46:42.048Z
Learning: Custom React Flow node types should be implemented as memoized components, using Handle components for connection points and supporting optional icons and labels.

Applied to files:

• src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx

🧬 Code graph analysis (1)

src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx (1)

src/frontend/src/controllers/API/helpers/constants.ts (1)

• getURL (37-47)

🔇 Additional comments (2)

src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx (2)

1-1: LGTM! Proper type imports added.

Adding Node and Edge type imports improves type safety for the request body structure.

---

53-57: API call structure is correct.

The POST request properly uses the typed requestBody. Once the null body issue is addressed, this will correctly send the flow structure to the backend.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Sending null body likely causes the 422 error.

When flow is missing or lacks nodes/edges, requestBody stays null. FastAPI/Pydantic endpoints typically reject null bodies with 422 validation errors because they expect an object matching the schema.

Apply this diff to always send a valid object structure:

-    let requestBody: { nodes: Node[]; edges: Edge[] } | null = null;
-    if (flow && flow.nodes && flow.edges) {
-      const { nodes, edges } = flow;
-      requestBody = {
-        nodes,
-        edges,
-      };
-    }
+    const requestBody: { nodes: Node[]; edges: Edge[] } = {
+      nodes: flow?.nodes ?? [],
+      edges: flow?.edges ?? [],
+    };

This ensures the backend always receives { nodes: [], edges: [] } rather than null, which should resolve the 422 error mentioned in the PR description.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	let requestBody: { nodes: Node[]; edges: Edge[] } | null = null;
	if (flow && flow.nodes && flow.edges) {
	const { nodes, edges } = flow;
	data["data"]["nodes"] = nodes;
	data["data"]["edges"] = edges;
	requestBody = {
	nodes,
	edges,
	};
	}
	const requestBody: { nodes: Node[]; edges: Edge[] } = {
	nodes: flow?.nodes ?? [],
	edges: flow?.edges ?? [],
	};

🤖 Prompt for AI Agents

In
src/frontend/src/controllers/API/queries/vertex/use-post-retrieve-vertex-order.tsx
around lines 45 to 52, requestBody can remain null when flow or its nodes/edges
are missing which causes a 422 from the FastAPI endpoint; change the logic to
always build a valid object by defaulting to { nodes: [], edges: [] } when flow
is absent or missing properties (e.g., set requestBody = { nodes: flow?.nodes ??
[], edges: flow?.edges ?? [] } or equivalent) so the backend always receives a
proper object instead of null.