Bug: Frontend hardcodes `event_delivery=POLLING` default, ignoring server config and stream toggle

[madhav165]

Bug Description

Summary

The Langflow frontend always defaults to EventDeliveryType.POLLING when eventDelivery is not explicitly passed, even though LANGFLOW_EVENT_DELIVERY defaults to streaming on the server. This means token events are buffered and delivered in bulk instead of streamed in real-time, regardless of server configuration or the stream toggle on components.

Affected File

src/frontend/src/utils/buildUtils.ts — line 239-242:

queryParams.append(
  "event_delivery",
  eventDelivery ?? EventDeliveryType.POLLING,
);

Expected Behavior

When eventDelivery is not explicitly provided by the caller, the default should be EventDeliveryType.STREAMING — consistent with the server-side default (LANGFLOW_EVENT_DELIVERY=streaming per the docs).

Actual Behavior

The frontend:

1. Sends event_delivery=polling in the query params, overriding the server default
2. Uses the polling client code path (customPollBuildEvents) instead of the SSE code path (performStreamingRequest)

This results in all build events — including individual token chunks — being buffered and returned as NDJSON instead of streamed via SSE in real-time.

Impact

• Token-by-token streaming in the Playground chat does not work even when the server is configured for streaming
• Components with streaming enabled (e.g., A2A clients) generate individual token events, but the user sees the full response appear at once
• The LANGFLOW_EVENT_DELIVERY environment variable has no practical effect because the frontend always overrides it

Root Cause

buildFlowVertices receives eventDelivery from BuildVerticesParams. When the caller (flowStore) does not set it, the ?? fallback on line 241 defaults to POLLING. This value controls both:

1. Server-side: the event_delivery query parameter — overrides the server's LANGFLOW_EVENT_DELIVERY config
2. Client-side: which code path is used — SSE (performStreamingRequest, line 369) vs polling (customPollBuildEvents, line 406)

The streaming code path already works correctly (lines 369-405). It is simply never reached.

Suggested Fix

Change the default on line 241:

  queryParams.append(
    "event_delivery",
-   eventDelivery ?? EventDeliveryType.POLLING,
+   eventDelivery ?? EventDeliveryType.STREAMING,
  );

The fallback in buildFlowVerticesWithFallback (lines 155-175) already handles the case where streaming is not supported — it catches the error and retries with EventDeliveryType.POLLING. So changing the default is safe.

Environment

• Langflow version: 1.8.1
• LANGFLOW_EVENT_DELIVERY: streaming (server default per docs)

Reproduction

1. Start Langflow with default configuration (or explicitly set LANGFLOW_EVENT_DELIVERY=streaming)
2. Open the Playground for any flow containing a streaming-capable component (e.g., an LLM or A2A client with stream toggle ON)
3. Send a message in the Playground chat
4. Open browser DevTools → Network tab
5. Find the POST .../build/{flow_id}/flow request
6. Inspect the query parameters — observe event_delivery=polling is sent regardless of server config
7. Find the subsequent GET .../build/{job_id}/events request
8. Observe Content-Type: application/x-ndjson (polling) instead of text/event-stream (SSE)
9. In the chat, the full response appears at once instead of streaming token-by-token

Expected behavior

When eventDelivery is not explicitly provided by the caller, the default should be EventDeliveryType.STREAMING — consistent with the server-side default (LANGFLOW_EVENT_DELIVERY=streaming per the docs).

Who can help?

@Cristhianzl

Operating System

langflow image

Langflow Version

1.8.1

Python Version

None

Screenshot

No response

Flow File

No response