server : print warning when HTTP timeout exceeded

[ggerganov]

Overview

Long-lasting (i.e. more than 10 mins) generations with stream: false, in router mode, get terminated by the should_stop() condition. However, we don't see any information about it in the logs.

Promoting the debug message to warning to help understand what is happing in such cases.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: NO

[kripper]

HTTP timeout (llama-server is not respecting the --timeout / HTTP libraries handle different timeouts) or the client is unexpectedly disconnecting (client-side timeout).
The task is canceled and the computed cache is released (this shouldn't be done IMO), so when the client retries the request, it starts from scratch, the timeout kicks in again and we end in a deadlock (#22160).

[ngxson]

I don't think there is a problem with server --timeout. It seems like most reported problems are due to the timeout from client side, not the server.

In any cases, we can simply bump --timeout to a very large number and remove this message, which can be a bit misleading

[kripper]

I don't think there is a problem with server --timeout. It seems like most reported problems are due to the timeout from client side, not the server.

Yes, it could be a client-side timeout.

In any cases, we can simply bump --timeout to a very large number and remove this message, which can be a bit misleading

I think it is important to detect both situations and explicitly show a message saying "Client disconnected unexpectedly" or "The request timed out on the server (adjust the --timeout argument if needed)."

[alexhalf]

I update my llama from b8895 to b9296 + use the same, but now MTP versions of models (qwen3.5-35b-3ab and qwen3.5-9B) and face to the problem with both. At first with 35b (slowly for me with cached prompt 25k context) and with qwen3.5-9b when my context about 190k and server have to spend more time with fast model 9b to invalidate all prompt cache . llama-swap have the same version, now I often see the stop message. And I can not continue chat with context because handling is stoped

[alexhalf]

My apologies.

I set that experimented config in my llama-swap
"Qwen3.5-9B-Q4_K_M":
cmd: |
/models/llm/llama-b9296/bin/helper.sh --port 8038 --model /models/Qwen3.5-9B-MTP-Q4_K_M.gguf --mmproj /models/qwen3.5-9b-mmproj-BF16.gguf
--reasoning off
-ngl 99
--ctx-size 262144
--spec-type draft-mtp
--batch-size 512
--ubatch-size 256
--flash-attn on
--jinja
--metrics
--mlock
--no-mmap
--cache-type-k q4_0
--cache-type-v q4_0
--parallel 1
--cont-batching
--temp 0.7
--top-p 0.95
--top-k 40
--slot-save-path /models/cache/qwen3.5-9b
--ctx-checkpoints 1024
--timeout 10
proxy: http://127.0.0.1:8038
proxyTimeout: 20
timeouts:
read: 30
write: 40
responseHeader: 50

and it does not matter

because after 120 seconds
i have stop signal

2.04.697.982 I slot print_timing: id 0 | task 0 | prompt processing, n_tokens = 116736, progress = 0.54, t = 119.08 s / 980.30 tokens per second
2.05.359.947 W srv next: stopping wait for next result due to should_stop condition (adjust the --timeout argument if needed)
2.05.359.969 W srv next: ref: #22907

but in llama-swap log I checked request headers

I updated my openclaw from 2026-4-23 to 2026-5-19 release, but I does not change my openclaw config. But I found issue with deepseek openclaw/openclaw#76117

I had ddefault timeout 30 minutes in openclaw and now
I tried set models.providers.NAME_OF_YOUR_PROVIDER.timeoutSeconds: 1210,
And it helped me

Now it's ok
99.765 I slot print_timing: id 0 | task 1 | prompt processing, n_tokens = 217686, progress = 1.00, t = 292.61 s / 743.96 tokens per second