EACI Development Journal · Reliability

How Do You Recover From Empty AI Stream Responses?

An empty stream is retried once through a simpler response path. That keeps a transient parser or provider edge case from becoming silence.

Reliability ~8 min issue-tagged
Issue this fixes

Streaming has more moving pieces than a normal JSON response: chunk framing, incremental decoding, content extraction, and a final flush. Any one of them can finish without yielding visible text.

Sanitized diagnostics recorded 24 `deepseek_empty_stream` events. The useful response was not an endless retry loop, but one bounded attempt through the non-stream path.

What was actually going wrong

The original path treated an orderly end-of-stream marker as proof that content had been delivered.

What I tried

What finally worked

When the accumulated visible stream is empty, the client logs the event and retries once without streaming.

Why it worked

The fallback removes chunk parsing from the equation and the single-retry limit prevents duplicate turns and runaway cost.

What I learned

A fallback should change the failure surface, not merely repeat it.

Where EACI uses this today

Main companion requests use the bounded recovery before presenting a failure.

This journal covers real engineering on EACI Companion / The Veil. Companions include Caelum, Chad, Natalia, Atreus, Luna, Roxy, and Cael. Journal articles stay family-safe in content. See Privacy and Ethics.