Functions: callable stream fails on the server's `: ping` heartbeat

[PSchmiedmayer]

Description

HTTPSCallable.stream() throws FunctionsError .dataLoss ("Unexpected format for streamed response.") as soon as the server sends an SSE comment line. firebase-functions (7.x) writes : ping\n\n whenever a streaming onCall has been quiet for 30 seconds (heartbeatSeconds, default 30), so any callable that takes longer than that without emitting a chunk fails on iOS. The Node client and the web SDK are fine with it.

The parser in Functions.swift only accepts lines that start with data::

for try await line in stream.lines {
  guard line.hasPrefix("data:") else {
    continuation.finish(throwing: FunctionsError(.dataLoss, ...))
    return
  }

Comment lines (: prefix) are part of the SSE spec and should be skipped. Same code on main today.

We ran into it with a function that proxies an image generation: nothing to stream for ~50 s, then the result. Every call over 30 s failed, the ones under 30 s worked. Setting heartbeatSeconds: null on the function works around it.

Reproducing the issue

1. Deploy (or run in the emulator) a streaming callable that waits before sending anything:

   export const slow = onCall(async (req, res) => {
     await new Promise((r) => setTimeout(r, 40_000));
     res.sendChunk("hello");
     return "done";
   });

2. Call it from iOS with Functions.functions().httpsCallable("slow").stream().
3. After 30 s the stream fails with Unexpected format for streamed response.

Firebase SDK Version

12.17.0

Xcode Version

27.0 (27A5252f)

Installation Method

Swift Package Manager

Firebase Product(s)

Functions

Targeted Platforms

iOS

Relevant Log Output

Error Domain=com.firebase.functions Code=15 "Unexpected format for streamed response."

[weevilgenius]

I'm seeing this issue as well. Temporary work around is to configure the cloud function with heartbeatSeconds: null to suppress the : ping messages but it's not ideal.

[rizafran]

Thanks for reporting. Do you have a sample app that reproduces the issue?

[PSchmiedmayer]

@rizafran thanks for looking into this!

The code up in the issue description is the minimally reproducible example I could come with; hope it helps 👍

[rizafran]

Thanks. It seems like the .dataLoss happens because the server automatically injects a : ping heartbeat to prevent intermediate proxies/load balancers from tearing down the connection. Since the default idle threshold is 30 seconds in heartbeatSeconds, and your function waits more than 30 seconds before sending its first chunk, the server emits a : ping. With this, setting heartbeatSeconds to more than 30 seconds or null would be the suggested fix in order to keep the connection alive.

Let me know if you have any other questions.

[PSchmiedmayer]

@rizafran sure; we followed the same workaround.
But might be nice if the client SDK would handle that automatically not not crash?

[weevilgenius]

@PSchmiedmayer I agree. It's unfortunate that a developer using the official SDK for both client and sever with default settings can get a crash because the server uses a feature the client does not appear to support. At the very least the client should silently swallow the : ping message and not terminate.