What happens
Run netclaw model discover <provider> (or netclaw model set, which probes for metadata) against a self-hosted openai-compatible server and you often get nothing on screen for several seconds, then the whole list lands at once. Against a server that's busy serving inference, it can sit silent long enough that you assume it hung. If the probe crosses 10 seconds it fails outright with Connection timed out after 10 seconds.
There's no way, while waiting, to tell "still talking to a slow server" apart from "stuck."
Why
Discovery is a single blocking GET /v1/models with a hard 10s cap, no retry, and no incremental output. Nothing renders until that one call returns:
- timeout setup:
|
using var timeoutCts = CancellationTokenSource.CreateLinkedTokenSource(ct); |
|
timeoutCts.CancelAfter(ProbeTimeout); |
- the blocking call:
|
using var response = await httpClient.SendAsync(request, timeoutCts.Token); |
- the 10s constant:
|
private static readonly TimeSpan ProbeTimeout = TimeSpan.FromSeconds(10); |
A self-hosted llama.cpp or vLLM box answering /v1/models while it's loading a model or saturated with requests is exactly the case that feels broken under this design.
The plain CLI path is worse than the wizard, too. The init wizard at least tracks elapsed probe time and can show it; netclaw model discover/set just awaits in silence.
Suggested direction
- Print a
probing <endpoint>... line with elapsed time (or a spinner) so a slow probe stops looking like a hang.
- Reconsider the fixed 10s timeout for self-hosted providers, or make it configurable. A cold vLLM/llama.cpp server can legitimately need longer than 10s for its first request.
- When the timeout does fire, say "still waiting, the server may be busy" rather than presenting a hard failure at exactly 10s, since the endpoint is frequently fine and just slow.
What happens
Run
netclaw model discover <provider>(ornetclaw model set, which probes for metadata) against a self-hostedopenai-compatibleserver and you often get nothing on screen for several seconds, then the whole list lands at once. Against a server that's busy serving inference, it can sit silent long enough that you assume it hung. If the probe crosses 10 seconds it fails outright withConnection timed out after 10 seconds.There's no way, while waiting, to tell "still talking to a slow server" apart from "stuck."
Why
Discovery is a single blocking
GET /v1/modelswith a hard 10s cap, no retry, and no incremental output. Nothing renders until that one call returns:netclaw/src/Netclaw.Providers/ProbeHelpers.cs
Lines 74 to 75 in 60601c6
netclaw/src/Netclaw.Providers/ProbeHelpers.cs
Line 87 in 60601c6
netclaw/src/Netclaw.Providers/ProbeHelpers.cs
Line 17 in 60601c6
A self-hosted llama.cpp or vLLM box answering
/v1/modelswhile it's loading a model or saturated with requests is exactly the case that feels broken under this design.The plain CLI path is worse than the wizard, too. The init wizard at least tracks elapsed probe time and can show it;
netclaw model discover/setjust awaits in silence.Suggested direction
probing <endpoint>...line with elapsed time (or a spinner) so a slow probe stops looking like a hang.