Commit 5c7fc1d
committed
fix(httpclient): raise image-host upload deadline to 120s
UploadTimeout is one constant shared by every image host in the uploader
registry, and the 60s whole-request deadline was too tight for all of
them. The same timeout failure was seen on pixhost and imgbox before
reelflix hosting was configured, so this is not one host being slow.
The deadline is not a transfer budget. The failure looks like:
Post "https://<host>/api/1/upload": context deadline exceeded
(Client.Timeout exceeded while awaiting headers)
"while awaiting headers" means the multipart body was already sent and
the deadline expired waiting on the host to answer, so what the ceiling
has to cover is host-side processing of a 5-8MB image. Every host is
slower at that than at a 1080p screenshot, which is why this shows up as
a 2160p problem across hosts rather than a per-host one.
imgbox spends the same budget three times per batch: its CSRF fetch and
token generation each clone the client at UploadTimeout before the upload
itself runs, so a slow host burns the ceiling on requests that publish
nothing.
The batch with recorded timings reported mean_attempt_duration=42.02s
across 6 attempts, and since attemptDurations records failed attempts
too, the 5 successes averaged around 38s. That is barely 1.5x headroom
for an operation whose duration is set by how fast a remote host answers.
120s restores roughly 3x.
UploadTimeout is consumed only by internal/imagehosting; every tracker
upload path uses DefaultTimeout, so no other deadline widens.1 parent d4ded9d commit 5c7fc1d
1 file changed
Lines changed: 6 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
11 | 11 | | |
12 | 12 | | |
13 | 13 | | |
14 | | - | |
| 14 | + | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
| 19 | + | |
15 | 20 | | |
16 | 21 | | |
17 | 22 | | |
| |||
0 commit comments