fix: reduce visual lag in frontend

[jordanrfrazier]

Reduces visual lag in the frontend when displaying events by batching certain execution events together and rendering them in a single redrawing. Also reduces the minimal visual build time, which may have performance impact on lower-end machines, so we may increase that a bit if there are concerns.

Previously, the visual build delay resulted in a Flow not visually completing until N*minimal_visual_build_time, where N is the number of layers in execution. Now, we batch events so they are allowed to be rendered in near-real-time.

Summary by CodeRabbit

Release Notes

• Performance

  • Optimized build event processing with batch handling for smoother UI responsiveness.
  • Added timing instrumentation to track build completion metrics.

• Improvements

  • Enhanced edge animation and state management during build execution.
  • Improved streaming request handling with batch event processing capabilities.

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

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

This PR introduces event batching for build operations across frontend and backend. The backend adds timing instrumentation to build completion logs. The frontend implements React 18 batching for specific events (end_vertex, build_start, build_end) while maintaining sequential processing for others. The implementation refactors event handling to use a centralized callbacks object and removes timing parameter passing.

Changes

Cohort / File(s)	Summary
Backend Build Instrumentation src/backend/base/langflow/api/build.py	Adds timing instrumentation to log build start time and completion metrics (elapsed time, vertex count, sum of vertex times).
Streaming API Enhancement src/frontend/src/controllers/API/api.tsx	Introduces optional onDataBatch callback to StreamingRequestParams for batched event processing; buffers complete JSON events per chunk and invokes onDataBatch if provided, with fallback to per-event onData processing.
Event Polling and Batching src/frontend/src/customization/utils/custom-poll-build-events.ts	Removes verticesStartTimeMs parameter; implements synchronous batch processing for batchable events (end_vertex, build_start, build_end) to enable React 18 batching; adds flow store integration for build status updates; introduces processEndVertexEvent helper.
Build Utilities Refactor src/frontend/src/utils/buildUtils.ts	Introduces BATCHABLE_EVENTS constant and BATCH_YIELD_MS delay; adds processEndVertexEvent helper for centralized end_vertex handling; refactors callbacks into eventCallbacks object; implements batch processing for batchable events with short yield to allow React batching; removes MIN_VISUAL_BUILD_TIME_MS constant.
Flow State Management src/frontend/src/stores/flowStore.ts, src/frontend/src/types/zustand/flow/index.ts	Refactors addDataToFlowPool to use immutable spread pattern instead of in-place mutation; adds clearAndSetEdgesRunning(nextIds?) method to selectively mark edges as running and update animation state.

Sequence Diagram(s)

sequenceDiagram
    participant Client as Client
    participant Stream as Streaming API
    participant Batch as Batch Processor
    participant Store as Flow Store
    participant UI as UI Component

    rect rgba(100, 150, 200, 0.5)
    Note over Client,UI: New Batching Flow
    end

    Client->>Stream: Request with onDataBatch callback
    Stream->>Stream: Buffer JSON events per chunk
    activate Stream
    Stream->>Stream: Collect into parsedEvents array
    Stream->>Batch: Check if batchable events present
    
    alt Batchable Events Found
        Batch->>Batch: Process end_vertex, build_start, build_end synchronously
        Batch->>Store: Update edge states & build status (batched)
        Batch->>Batch: Yield BATCH_YIELD_MS for React batching
        Batch->>Client: onDataBatch(parsedEvents) returns boolean
        
        alt Should Continue
            Client->>UI: Batch UI update
            UI->>UI: React batches state updates
        else Abort
            Stream->>Stream: Abort request
        end
    else Non-Batchable Events
        Stream->>Batch: Process per event asynchronously
        Batch->>Client: onData(event) for each event
    end
    deactivate Stream

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

---

Important

Pre-merge checks failed

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

❌ Failed checks (1 error, 3 warnings)

Check name	Status	Explanation	Resolution
Test Coverage For New Implementations	❌ Error	PR introduces significant functionality (processEndVertexEvent, BATCHABLE_EVENTS batching, onDataBatch streaming) without adding corresponding test files in established test directories.	Add test files: buildUtils.test.ts for batching logic, flowStore.test.ts for clearAndSetEdgesRunning, api.test.tsx for onDataBatch callback, and backend tests for timing instrumentation in build.py.
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% 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	PR introduces significant new implementations across 6 files including critical functionality like processEndVertexEvent and batching logic, but has zero tests for new exports and complex features.	Add comprehensive test coverage: create buildUtils.test.ts, custom-poll-build-events.test.ts, flowStore tests, api.test.ts, and backend timing tests before merging.
Test File Naming And Structure	⚠️ Warning	Pull request introduces substantial functionality changes without corresponding test files for new critical functions and features.	Add test files following project patterns: create frontend tests for processEndVertexEvent and BATCHABLE_EVENTS batching logic; add backend tests for timing instrumentation; ensure coverage of specific issues like missing build_start event handling and JSON error handling.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: reduce visual lag in frontend' directly addresses the PR's main objective of reducing visual lag by batching and optimizing frontend rendering, accurately summarizing the primary change.
Excessive Mock Usage Warning	✅ Passed	The custom check for excessive mock usage in test files is not applicable to this PR. No test files were modified; only six implementation files were changed.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch reduce-lag-in-fe

---

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

[github-actions]

Frontend Unit Test Coverage Report

Coverage Summary

Lines	Statements	Branches	Functions
	19.03% (6177/32457)	12.53% (3175/25321)	12.75% (888/6962)

Unit Test Results

Tests	Skipped	Failures	Errors	Time
2345	0 💤	0 ❌	0 🔥	32.356s ⏱️

[codecov]

Codecov Report

❌ Patch coverage is 58.97436% with 48 lines in your changes missing coverage. Please review.
✅ Project coverage is 35.53%. Comparing base (e346812) to head (0a584dd).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/frontend/src/utils/buildUtils.ts	73.68%	13 Missing and 7 partials ⚠️
...rc/customization/utils/custom-poll-build-events.ts	5.55%	17 Missing ⚠️
src/frontend/src/controllers/API/api.tsx	0.00%	10 Missing ⚠️
src/frontend/src/stores/flowStore.ts	92.30%	0 Missing and 1 partial ⚠️

❌ Your project status has failed because the head coverage (41.87%) is below the target coverage (60.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #11686      +/-   ##
==========================================
+ Coverage   35.45%   35.53%   +0.08%     
==========================================
  Files        1527     1527              
  Lines       73570    73609      +39     
  Branches    11061    11071      +10     
==========================================
+ Hits        26081    26158      +77     
+ Misses      46074    46028      -46     
- Partials     1415     1423       +8     

Flag	Coverage Δ
backend	56.34% <ø> (+0.04%)	⬆️
frontend	17.18% <58.97%> (+0.20%)	⬆️
lfx	41.87% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/frontend/src/stores/flowStore.ts	13.03% <92.30%> (+2.68%)	⬆️
src/frontend/src/controllers/API/api.tsx	8.93% <0.00%> (-0.32%)	⬇️
...rc/customization/utils/custom-poll-build-events.ts	13.15% <5.55%> (-0.18%)	⬇️
src/frontend/src/utils/buildUtils.ts	19.94% <73.68%> (+13.93%)	⬆️

... and 7 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In `@src/frontend/src/customization/utils/custom-poll-build-events.ts`:
- Line 67: Replace the blind JSON.parse in the mapping over eventLines with safe
per-line parsing: iterate eventLines (the eventLines variable) and for each line
attempt JSON.parse inside a try/catch (the code that creates events from
eventLines), skip or filter out malformed lines, and optionally log or collect
parse errors rather than letting a single bad line throw and abort the whole
poll cycle; ensure the variable events (where the parsed results are stored)
only contains successfully parsed objects.
- Around line 85-102: The batched handler ignores `build_start` events when
`ev.data?.id` is missing, so add the same start-time behavior as the
single-event handler: in the `else if (ev.event === "build_start")` branch (near
processEndVertexEvent and useFlowStore.getState().updateBuildStatus), always
call the build start setter when id is absent (e.g., invoke the equivalent of
setBuildStartTime(Date.now()) or the store method that records start time), then
set result = true; apply the identical change to the two onDataBatch handlers in
buildUtils.ts that currently guard on `ev.data?.id` so they also record
buildStartTime for empty-data `build_start` events.

In `@src/frontend/src/utils/buildUtils.ts`:
- Around line 315-321: The build_start handler in the onDataBatch blocks only
updates per-vertex status when data?.id is present and misses the initial
build_start with no data.id; modify the build_start branches (both the block
around the current code and the similar block at the other location) to call
setBuildStartTime(Date.now()) when data?.id is falsy (i.e., add an else branch
that invokes setBuildStartTime(Date.now())), keeping the existing
useFlowStore.getState().updateBuildStatus([data.id], BuildStatus.BUILDING) for
the per-vertex case so processEndVertexEvent and flowState.buildStartTime behave
correctly.

🧹 Nitpick comments (3)

src/frontend/src/stores/flowStore.ts (1)

984-997: Clean implementation with proper immutability.

Unlike the existing updateEdgesRunningByNodes (line 953) and clearEdgesRunningByNodes (line 972) which mutate edge objects in place before calling set(), this new method correctly spreads each edge into a new object. The Set-based lookup is a good choice for efficiency. Consider retrofitting the older methods to follow this same immutable pattern in a follow-up.

src/frontend/src/controllers/API/api.tsx (1)

249-249: Consider documenting the onDataBatch contract.

The return semantics (false = abort) match onData, but the fact that onDataBatch receives all parsed events from a single network chunk (not necessarily a logical batch) is worth a brief JSDoc note for future maintainers.

src/frontend/src/utils/buildUtils.ts (1)

300-349: Duplicated onDataBatch logic between DIRECT and STREAMING modes.

The onDataBatch handler bodies at lines 300–349 (DIRECT) and 433–478 (STREAMING) are virtually identical. Extract a shared helper to avoid maintaining parallel copies of the batching logic.

Proposed extraction

+function processBatchedEvents(
+  events: object[],
+  buildResults: boolean[],
+  callbacks: typeof eventCallbacks,
+): Promise<boolean> {
+  let hadBatchable = false;
+  for (const event of events) {
+    const type = event["event"] as string;
+    const data = event["data"];
+
+    if (BATCHABLE_EVENTS.has(type)) {
+      let result: boolean;
+      if (type === "end_vertex") {
+        result = processEndVertexEvent(data, buildResults, callbacks);
+      } else if (type === "build_start") {
+        if (data?.id) {
+          useFlowStore.getState().updateBuildStatus([data.id], BuildStatus.BUILDING);
+        } else {
+          useFlowStore.getState().setBuildStartTime(Date.now());
+        }
+        result = true;
+      } else {
+        if (data?.id) {
+          useFlowStore.getState().updateBuildStatus([data.id], BuildStatus.BUILT);
+        }
+        result = true;
+      }
+      if (!result) return Promise.resolve(false);
+      hadBatchable = true;
+    } else {
+      const result = await onEvent(type, data, buildResults, callbacks);
+      if (!result) return false;
+    }
+  }
+  if (hadBatchable) {
+    await new Promise((resolve) => setTimeout(resolve, BATCH_YIELD_MS));
+  }
+  return true;
+}

Then use onDataBatch: (events) => processBatchedEvents(events, buildResults, eventCallbacks) in both places.

Also applies to: 433-478

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Missing error handling for malformed JSON lines.

If any line from the polling response is not valid JSON, JSON.parse(line) will throw and crash the entire poll cycle. The streaming path in api.tsx handles this gracefully with try/catch, but polling does not.

Proposed fix

-    const events = eventLines.map((line) => JSON.parse(line));
+    const events: any[] = [];
+    for (const line of eventLines) {
+      try {
+        events.push(JSON.parse(line));
+      } catch (e) {
+        console.warn("[poll] Skipping malformed event line:", line);
+      }
+    }

📝 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

	const events = eventLines.map((line) => JSON.parse(line));
	const events: any[] = [];
	for (const line of eventLines) {
	try {
	events.push(JSON.parse(line));
	} catch (e) {
	console.warn("[poll] Skipping malformed event line:", line);
	}
	}

🤖 Prompt for AI Agents

In `@src/frontend/src/customization/utils/custom-poll-build-events.ts` at line 67,
Replace the blind JSON.parse in the mapping over eventLines with safe per-line
parsing: iterate eventLines (the eventLines variable) and for each line attempt
JSON.parse inside a try/catch (the code that creates events from eventLines),
skip or filter out malformed lines, and optionally log or collect parse errors
rather than letting a single bad line throw and abort the whole poll cycle;
ensure the variable events (where the parsed results are stored) only contains
successfully parsed objects.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

build_start without data.id silently skipped — buildStartTime never set in batched path.

The backend emits a general build_start event with empty data (event_manager.on_build_start(data={}) in build.py line 507). When this event arrives in a batch, the if (ev.data?.id) guard causes it to be silently treated as a no-op. However, the non-batched onEvent handler (buildUtils.ts lines 720–727) sets setBuildStartTime(Date.now()) for this case, which is needed for segment duration tracking in processEndVertexEvent (line 581).

This same gap exists in the onDataBatch handlers in buildUtils.ts (~lines 315–321 and ~447–452).

Proposed fix for this file (apply the same pattern in buildUtils.ts onDataBatch blocks)

           if (ev.event === "end_vertex") {
             result = processEndVertexEvent(ev.data, buildResults, callbacks);
           } else if (ev.event === "build_start") {
-            if (ev.data?.id) {
+            if (ev.data?.id) {
               useFlowStore
                 .getState()
                 .updateBuildStatus([ev.data.id], BuildStatus.BUILDING);
+            } else {
+              useFlowStore.getState().setBuildStartTime(Date.now());
             }
             result = true;

📝 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

	if (ev.event === "end_vertex") {
	result = processEndVertexEvent(ev.data, buildResults, callbacks);
	} else if (ev.event === "build_start") {
	if (ev.data?.id) {
	useFlowStore
	.getState()
	.updateBuildStatus([ev.data.id], BuildStatus.BUILDING);
	}
	result = true;
	} else {
	// build_end
	if (ev.data?.id) {
	useFlowStore
	.getState()
	.updateBuildStatus([ev.data.id], BuildStatus.BUILT);
	}
	result = true;
	}
	if (ev.event === "end_vertex") {
	result = processEndVertexEvent(ev.data, buildResults, callbacks);
	} else if (ev.event === "build_start") {
	if (ev.data?.id) {
	useFlowStore
	.getState()
	.updateBuildStatus([ev.data.id], BuildStatus.BUILDING);
	} else {
	useFlowStore.getState().setBuildStartTime(Date.now());
	}
	result = true;
	} else {
	// build_end
	if (ev.data?.id) {
	useFlowStore
	.getState()
	.updateBuildStatus([ev.data.id], BuildStatus.BUILT);
	}
	result = true;
	}

🤖 Prompt for AI Agents

In `@src/frontend/src/customization/utils/custom-poll-build-events.ts` around
lines 85 - 102, The batched handler ignores `build_start` events when
`ev.data?.id` is missing, so add the same start-time behavior as the
single-event handler: in the `else if (ev.event === "build_start")` branch (near
processEndVertexEvent and useFlowStore.getState().updateBuildStatus), always
call the build start setter when id is absent (e.g., invoke the equivalent of
setBuildStartTime(Date.now()) or the store method that records start time), then
set result = true; apply the identical change to the two onDataBatch handlers in
buildUtils.ts that currently guard on `ev.data?.id` so they also record
buildStartTime for empty-data `build_start` events.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Same build_start (no data.id) gap as in the polling handler.

The initial build_start event emitted by the backend has no data.id and should trigger setBuildStartTime(Date.now()). Both onDataBatch blocks only handle the per-vertex case (data?.id), silently skipping the timer initialization. This will cause processEndVertexEvent (line 580) to skip segment-duration tracking since flowState.buildStartTime will be null/stale.

See the fix proposed in the custom-poll-build-events.ts review comment — apply the same else { setBuildStartTime(Date.now()) } branch here.

Also applies to: 447-452

🤖 Prompt for AI Agents

In `@src/frontend/src/utils/buildUtils.ts` around lines 315 - 321, The build_start
handler in the onDataBatch blocks only updates per-vertex status when data?.id
is present and misses the initial build_start with no data.id; modify the
build_start branches (both the block around the current code and the similar
block at the other location) to call setBuildStartTime(Date.now()) when data?.id
is falsy (i.e., add an else branch that invokes setBuildStartTime(Date.now())),
keeping the existing useFlowStore.getState().updateBuildStatus([data.id],
BuildStatus.BUILDING) for the per-vertex case so processEndVertexEvent and
flowState.buildStartTime behave correctly.

[Cristhianzl]

lgtm

[stevehaertel]

Note for the record: I tested this successfully with a large flow and immediately saw a drastic difference.