- Shipped
- October 7, 2026 at 5:14 PM UTC
- Author
- Kamo
- Commit
- aaf9f56
LibreTranslate keeps translating a request after its client stops waiting, so every timeout was work done for no one. Measured over six hours on 2026-10-07: 46 of 303 requests abandoned mid-translation, and KBService giving up on its 120-second read 48 times while this service went on working for it. - One deadline covers the whole request (every key of a batch, both passes of a text that lost a protected term), instead of a fresh 100 seconds per provider call. Keys still waiting when it runs out fail without being sent. - Callers can say how long they will wait (X-Translate-Wait-Seconds, up to 10 minutes). The default stays 100 seconds, inside the 120-second read timeout most callers use. A longer wait marks the request as background work. - A timeout is no longer retried. The retry always got the ~9 seconds a 90-second first attempt left, never finished, and was translated in full anyway (22 of 22 in six hours). - At most 3 LibreTranslate calls in flight per pod, 2 of them for background work. The queue is here, where a request whose caller has given up is never sent, at least two of LibreTranslate's eight workers stay free for its readiness probe, and a chat message never waits behind help articles. - A long text that lost a protected term is translated a second time only if the time left is at least what the first pass took.