SSE ping event fails to parse: EventSourceMessage.data is empty for ping events

[hllshiro]

Problem

When using dify-ai-provider with Dify API, SSE ping events (event: ping\n\n) cause a parse error in @ai-sdk/provider-utils's parseJsonEventStream. The error appears as a stream error in the console.

Root Cause

Dify API sends pings in SSE event-type format:

event: ping

But @ai-sdk/provider-utils parseJsonEventStream (used by createEventSourceResponseHandler) only destructures the data field from EventSourceMessage, discarding the event field:

// @ai-sdk/provider-utils parse-json-event-stream.ts
async transform({ data }, controller) {
  if (data === '[DONE]') return;
  controller.enqueue(await safeParseJSON({ text: data, schema }));
}

When event: ping\n\n arrives:

• EventSourceParserStream produces { event: "ping", data: "" }
• { data } destructuring yields empty string ""
• safeParseJSON({ text: "", schema }) fails — empty string is not valid JSON
• Transform enqueues error event

Why ping format changed

Dify uses event: ping (SSE event-type field) since commit 7753ba2d37 (April 2024). The ping string is a valid SSE event type per the SSE spec, not JSON data.

Suggested Fix

In the SSE transform within dify-chat-language-model.ts, before calling safeParseJSON, check if the message is a ping by inspecting the event field (or detecting empty data with a ping event type), and skip/enqueue a synthetic success result:

async transform({ event, data }, controller) {
  if (data === '[DONE]') return;
  // Handle ping events that have no JSON data
  if (event === 'ping' || (data === '' && event === 'ping')) {
    controller.enqueue({ success: true, value: { event: 'ping' } });
    return;
  }
  controller.enqueue(await safeParseJSON({ text: data, schema }));
}

Reproduction

1. Configure any Dify app (chat/agent/workflow/completion) with streaming enabled
2. Send a message and observe the console
3. The event: ping SSE frames trigger parse errors from @ai-sdk/provider-utils

The existing switch case at dify-chat-language-model.ts:480 correctly handles { event: 'ping' }, but it's never reached because the transform fails before the case can match.

[warmwind]

Thanks for the report. However, I don’t think the bare event: ping frame is the source of this error. I reproduced the behavior with eventsource-parser@3.0.6, and that frame never reaches safeParseJSON.

eventsource-parser follows the SSE specification and does not dispatch an event when its data buffer is empty. I tested the three relevant cases:

Frame	Result
event: ping\n\n — what Dify sends	Discarded by the parser; the JSON transform never sees it
event: ping\ndata: \n\n	Produces a JSONParseError with text === ""
data: {"event":"ping"}\n\n	Parses successfully

Dify’s documentation shows event: ping as a bare keepalive. Its own code also checks chunk.strip() == "event: ping", which would not match if a data: line were present.

Also, a parsing failure does not terminate the provider’s transform. It enqueues an error part for that payload, skips it, and continues processing subsequent events.

If the logged Text: value is empty, the input would have to contain an actual empty data: line; a bare event: ping frame cannot produce that error. If Text: is non-empty, it should show us which payload failed.

Unless logging was disabled with logger: false or a custom logger suppresses errors, the provider should already have printed this line to console.error; enabling logMessages is not necessary:

[dify-ai-provider] Dify stream parse error {
  error: 'AI_JSONParseError: JSON parsing failed: Text: <data payload>. ...'
}

Could you paste that log line—especially the Text: value—after redacting any sensitive content?

That should be enough to diagnose the problem without changing the code. Possible causes include an intermediary modifying the SSE stream or a particular Dify version or app type emitting a non-JSON data: payload. I’ll be happy to fix it once we know which one it is.

[hllshiro]

The issue has been identified. I was using a non-standard middleware to proxy Dify’s SSE stream in order to hide the API key from the frontend. The middleware did not handle keep-alive data correctly, causing this message to be incorrectly converted into a regular message and sent to the frontend. Thanks for your help! :)