Make the download deadline an idle deadline and cancel failed bodies (closes #24)
check / check (push) Successful in 17s
check / check (push) Successful in 17s
downloadTimeoutMs now aborts a file or thumbnail download only when no bytes have arrived for that long (default 60 s, was a 600 s cap on the whole transfer), so a slow download that keeps making progress completes. The abort reason is still a TimeoutError, so retry classification is unchanged. A download that fails before reading the whole response body cancels it, including when the temp file cannot be opened or the header is malformed, so a failed file no longer holds its connection. Model: opus-5-5
This commit was merged in pull request #88.
This commit is contained in:
@@ -363,19 +363,22 @@ and a half seconds of waiting. `sleep` and `random` are injectable through the
|
||||
same option, which is how the test suite exercises the whole policy without
|
||||
waiting.
|
||||
|
||||
Two deadlines, applied with `AbortSignal.timeout()` and renewed for each
|
||||
attempt:
|
||||
Two deadlines, renewed for each attempt:
|
||||
|
||||
| Option | Default | Applies to |
|
||||
| ------------------- | -------- | ------------------------------------------- |
|
||||
| `requestTimeoutMs` | `30000` | `getJSON`, `postJSON`, `putJSON`, `putFile` |
|
||||
| `downloadTimeoutMs` | `600000` | file and thumbnail body transfers |
|
||||
| Option | Default | Applies to | Kind |
|
||||
| ------------------- | ------- | ------------------------------------------- | ------------------------------------- |
|
||||
| `requestTimeoutMs` | `30000` | `getJSON`, `postJSON`, `putJSON`, `putFile` | the whole request |
|
||||
| `downloadTimeoutMs` | `60000` | file and thumbnail downloads | idle: no bytes received for this long |
|
||||
|
||||
They are separate because one number cannot serve both: a value short enough to
|
||||
keep a hung API call from stalling a backup would cancel a legitimate
|
||||
multi-gigabyte download. The download deadline covers the body, not just the
|
||||
headers — `getFileStream` returns as soon as headers arrive, so a deadline that
|
||||
only guarded the initial request would leave the same hang one layer down.
|
||||
They are different kinds because a download's length depends on the file and the
|
||||
link: a whole-transfer deadline short enough to catch a hung connection would
|
||||
cancel a large video on a slow link that is still making progress. The download
|
||||
deadline restarts every time bytes arrive, so a slow download runs as long as it
|
||||
keeps moving, and one that stalls is aborted after 60 seconds of silence. It
|
||||
covers the wait for the headers and the body — `getFileStream` returns as soon
|
||||
as headers arrive, so a deadline that only guarded the initial request would
|
||||
leave the same hang one layer down. There is no limit on the total length of a
|
||||
download.
|
||||
|
||||
**Non-idempotent requests are not blindly replayed.** `postJSON` and `putJSON`
|
||||
send every `POST` and `PUT` in the endpoint list above; some of them change
|
||||
|
||||
Reference in New Issue
Block a user