A timed-out request is sent three more times at the full timeout, up to eight minutes before an error

[DevEmperor]

Split out of #437, from the same email: after a WhatsApp call, the reporter's spinner had been
running for about 700 s.

The arithmetic

executeForBody(maxRetries = 3) retries every kind for which isRetryable is true (TIMEOUT,
NETWORK, SERVER_ERROR and UNKNOWN), with RETRY_DELAY_MS = 3000 between attempts. For a
dictation, the per-operation and the whole-call timeout are both the user's Request timeout
(default 120 s). So a connection that stalls costs this much, whether the network changed under an
upload or the phone went into a call:

4 × 120 s + 3 × 3 s  =  489 s  ≈  8 minutes

With the timeout raised to 180 s, it is about 12 minutes. Soniox and AssemblyAI poll on their own
5-minute budget on top of that.

A retry earns its keep after an error that came fast: a refused connection, a reset, a 502. That is
what the retries are for, and each one costs seconds. A full-length timeout is a different thing. The
budget the user chose is already spent, and repeating it three times multiplies the wait they asked
for by four. #363 is the same pattern on the watch.

Being offline is not the problem. DNS fails at once there, and the error arrives after about 9 s. The
problem is a connection that stalls.

What to change

1. Make a timeout that used the whole budget terminal, and let fast transport errors keep their
   three retries. That needs executeForBody to tell "timed out" apart from "failed quickly". The
   attempt's elapsed time is already measured (startedNanos). After the error, the resend chip is
   the retry, and the user decides whether to wait another round.
2. Worth checking: when the active network drops or changes during a request
   (ConnectivityManager.NetworkCallback), cancel the stalled call and retry once on the new network
   straight away instead of waiting out the read timeout. If it was the call that moved the
   connection, that is what would have helped in the reported case.
3. The file import keeps its own budgets (Suggested Optional UI Enhancement: Step-by-Step Video/Audio Transcription Progress #337). This issue is about dictation, rewording and the
   other calls that use Request timeout.

Related

#354/#355 (real timeout, elapsed seconds), #337 (the app's timeout map), #363 (the watch's version of
this).

[DevEmperor]

Fixed in 4ab5bd7. It will be in the next release.

Reproduced first on an emulator, against a mock provider that reads the upload and then never answers. That is a stalled connection as the phone sees it. Request timeout was set to 30 s to keep the runs short:

	Requests sent	Error after
Before	4, 33 s apart ("Retrying… (2)", "(3)", "(4)")	129 s
After	1	30 s
After, default 120 s	1	120 s (was about 8 min)

What changed. A retry now starts only while the request is still within the time one attempt may take. That is the same whole-call budget OkHttp is given:

• the Request timeout for dictation and rewording;
• the import's own 900 s for a shared file (Suggested Optional UI Enhancement: Step-by-Step Video/Audio Transcription Progress #337, unchanged).

Errors that come back fast keep their three retries. Three quick 503s are still retried 3 s apart, and the fourth attempt lands the text.

After a stall, the error and the resend chip now appear after one timeout. With Offline fallback on, the on-device model takes over after one timeout instead of four.

One departure from the plan: the rule looks at the time spent, not at the kind of error. A gateway that gives up after a long wait answers with a 5xx, not a timeout (Cloudflare's 524 comes after 100 s). Retrying that multiplied the wait in exactly the same way.

Point 2, the network callback, was checked and not built. I switched Wi-Fi off 7 s into a stalled request:

• Android aborted the socket at once.
• The retry went out over LTE 3 s later.
• The dictation landed after 10.8 s.

So a network that goes away already ends the request quickly, and a fast error keeps its retry. What remains is a connection that stalls while its network stays up. No network callback would notice that, and it now ends after one timeout.

Left alone: Soniox's and AssemblyAI's 5-minute polling budget. It waits for the provider's progress through short requests, and a poll that stalls now ends like any other request.

The other half of the email, a stop that looks like the dictation was thrown away, stays open as #437.