Is there a documented recovery when an LLM stream starts but stalls before a sentence completes?

pipecat 1.10.0, OpenAIResponsesLLMService with streaming, Telnyx transport, 8 kHz phone audio.

On one live call the LLM returned first tokens quickly (ttfb 1.4 s average, 2.9 s max) but four replies in a row then streamed so slowly that no sentence boundary was reached in 3.5 to 8.9 seconds, so nothing was sent to TTS. Each reply was then cancelled by the caller's next words, the pipeline logged "PipelineWorker heartbeat frame not received for more than 10.0 seconds" several times, and the caller heard silence until they hung up. Two other calls in the same half hour logged 20 to 22 second replies.

The docs describe retry_on_timeout and retry_timeout_secs on the LLM service. In this case the request had already produced tokens, so I am not sure whether that setting applies.

Is there a documented pattern for a stream that has started and then stalls, for example a per-stream idle timeout that cancels and retries, or a fallback LLM service? If not, would a feature request for a stream idle timeout on the LLM service be welcome? I can add a stock repro with a mock LLM service that streams slowly if that helps.