Empty transcript + "network connection was lost" error on short (~10s) dictations, no VPN/security software

[TeamReAccount]

Describe the bug

Dictation frequently fails with an empty transcript, immediately followed by a Post-Process error "The network connection was lost." This happens even on very short recordings (as short as ~10 seconds of speech), not just long ones.

Run Log pipeline observed

1. Capture Context - succeeds normally
2. Transcribe Audio - "Sent audio to the configured transcription model (empty transcript)"
3. Post-Process - "Error: The network connection was lost."

What I've ruled out

• No VPN active
• No firewall/security software (Little Snitch, LuLu, etc.) running
• Wi-Fi appears stable, other apps/websites aren't dropping connection
• Happens on both long and short (~10s) dictations, so doesn't seem size/timeout related

Expected behavior

Either a successful transcript, or a clearer error distinguishing "transcription provider returned nothing" from an actual client-side network drop, plus a retry path that doesn't require re-recording.

Environment

• App: FreeFlow 1.1 (macOS)
• Transcription provider: Groq (default)

[elohela-dev]

I hit this exact symptom (FreeFlow 1.2.1, macOS 26 / Darwin 25.6.0) and root-caused it — it's not the app's request code and not the user's connection. It's HTTP/3/QUIC being broken on the local network, and URLSession using it for Groq anyway.

Root cause

api.groq.com is fronted by Cloudflare, which publishes an HTTPS (type 65) DNS record advertising alpn="h3,h2". Modern macOS URLSession honors HTTPS RRs and will connect over QUIC (UDP 443) on the very first connection — no prior Alt-Svc needed, and URLRequest.assumesHTTP3Capable doesn't gate this path. On networks whose routers/middleboxes mangle UDP 443 (my case: a Telekom-style hotel/home router in Berlin), the QUIC flow dies mid-transfer and surfaces as NSURLErrorDomain -1005 "The network connection was lost" — even on a fresh ephemeral session, so LLMAPITransport's no-connection-reuse design doesn't help.

Evidence

• The same audio file + same API key transcribed fine via curl (which doesn't do HTTPS-RR/h3) while FreeFlow failed — 4/4 successes vs. repeated -1005.
• A standalone Swift repro using the same pattern as LLMAPITransport (ephemeral URLSessionConfiguration, uploadTask, fresh session per request) failed 4/4 with -1005 to api.groq.com on that network.
• Same-size URLSession POST to httpbin.org (no HTTPS RR) → HTTP 200. Same POST to www.cloudflare.com (has h3 HTTPS RR) → -1005. The failure tracks the DNS record, not the payload or the host's app layer.
• Small GETs sometimes survive; uploads die — consistent with QUIC flows being throttled/killed rather than cleanly blocked (a clean UDP block would fall back to TCP).

This also explains the profile in this issue: short recordings failing, no VPN/firewall, other apps fine (browsers handle h3 fallback more aggressively; curl doesn't use h3 at all).

Workaround that fixed it for me

A tiny localhost HTTP relay that forwards to api.groq.com over plain TCP/TLS, with FreeFlow's API Base URL set to http://127.0.0.1:8399/openai/v1. Dictation went from ~100% failure to 100% success instantly, same network, no other changes.

Possible fixes in FreeFlow

1. Fallback retry over TCP: on -1005/-1004, retry once with an URLSession configured to avoid h3. There's no public "disable h3" knob, but a retry through a URLSessionConfiguration with connectionProxyDictionary pointing at a trivial in-process TCP path — or simply retrying via a Network.framework/NWConnection TCP+TLS request for the multipart POST — would sidestep it.
2. At minimum, surface the error distinctly ("connection lost mid-upload — your network may be blocking HTTP/3/QUIC; try a different network") instead of letting it read as "no internet", which sends users down the wrong debugging path (it did for me and, I suspect, for this issue's reporter).

Happy to share the Swift repro or relay script if useful.