A Multipart Timeout Answers One Question Out Of Four

A dev.to triage note on speech-to-text for an edtech support queue makes a claim worth stealing: treat a long recording as an ingestion workflow, not one giant API call ^[1]. That reframing matters because, as the post puts it, wrapping the whole operation in fetch() and one generic error handler hides two failures with different costs, and the design job is to keep them visible ^[2]. The post splits the request into four decisions: can the application accept the file, did the upload finish, did transcription return a result, and is that result good enough for ticket triage ^[3]. Each decision needs its own state and timestamp ^[4]. A multipart timeout answers only the second one ^[5]. That is the whole diagnosis. Teams that report "the API timed out" have collapsed four transitions into one label, and then retry as though all four failed the same way. Retry policy is where the collapse costs money. A local file-size rejection should make no network request at all ^[6]. A 429 may be retriable with a capped delay and Retry-After ^[7]. A client-side deadline that fires after an upload is ambiguous: the server could have accepted the body even though the client never received confirmation ^[8], and retrying with a new job ID can create two transcripts for one support ticket ^[9]. The author is direct that fetch does not turn a network deadline into proof that the remote inference did not run ^[10], which is why the application needs its own idempotency or deduplication policy keyed by a stable recording ID ^[11]. In Node, the advice is to put an AbortController around the operation whose deadline you are actually measuring, and to record whether the abort happened while constructing the body, sending bytes, waiting for a response, or processing the response ^[12]. The sample gate is small and explicit: 25 MiB of audio plus 1 MiB of assumed multipart overhead ^[13][14], a 26 MiB request ceiling, or 27,262,976 bytes ^[15]. Accepted files move to ready_for_upload, rejected ones to needs_shorter_segment ^[16]. The post is careful that these are product settings rather than service limits ^[17], sized to leave room for the proxy and deployment environment sitting between the client and the API ^[18]. Rejected recordings are retained locally, with a request for a shorter segment or a route through an approved asynchronous path ^[19], and no silent compression of speech until the quality impact has been measured ^[20]. The retry helper treats 429 and 500 to 599 as retriable, stops at attempt 3, honours Retry-After when present, and otherwise waits min(8.0, 2**attempt plus up to 0.25 seconds of jitter) ^[21][22][23]. Given the attempt cap, the largest delay the function can compute is 4.25 seconds, so the 8-second ceiling never binds ^[24]. Harmless, but it is the kind of unreachable guard that later gets quoted as if it were the real bound. The testing point is the sharpest part. The author makes 429 an explicit fixture in the eval harness and inspects the resulting state transition, rather than treating a green retry test as evidence that the whole ingestion path is safe ^[25], because the transport test can pass while the classifier sees duplicate work, the support agent gets a stale route, and prompt tokens are spent on a transcript that should never have entered the downstream pipeline ^[26]. The quality gate exists for a matching reason: a fast transcript that drops the sentence containing a student's account number can route a ticket to the wrong team ^[27], while a perfect transcript can arrive late enough to make the queue stale ^[28]. Keep the original recording until there is a confirmed result or a deliberate human fallback ^[29].