mirror of
https://gitee.com/mateos/mateclaw.git
synced 2026-09-13 19:23:42 +08:00
527a67374d
Two real bugs the user restart surfaced — both turned healthy providers into HARD-removed false positives. Bug #1 — URL duplication OpenAiCompatibleListModelsProbe always concatenated /v1/models, so providers whose Base URL already includes the version segment got the wrong URL: LMStudio http://localhost:1234/v1 → /v1/v1/models → 404 ZhipuAI .../api/paas/v4 → /v4/v1/models → 404 Fix: detect a trailing /vN suffix and append /models instead. Six unit tests in OpenAiCompatibleListModelsProbeTest lock the rule down. Bug #2 — 404 false positives Kimi for Coding API does not expose /v1/models even though chat works fine, so the probe correctly received a 404 and incorrectly HARD-removed the provider from the pool. Other vendors will hit the same — listing is not a universal contract. Fix: classify HTTP responses semantically. 401 / 403 → HARD remove (real auth failure) 404 / 405 / 410 → fail-open (endpoint missing, server may be alive) other 4xx / 5xx → fail-open (probe inconclusive — let chat decide) network errors → fail (unreachable) This is the same philosophy as ChatGPTOAuthStatusProbe: when we cannot cheaply confirm health, we do not proactively penalize the provider. Same logic applied to Anthropic + DashScope probes for consistency. Net effect on the user deployment after restart: - kimi-code stays in pool (404 → fail-open) → primary path works again - lmstudio + zhipu-cn also stay in pool (URL bug fixed) - dashscope + ollama unchanged (real 200 OK) Tests: 6 new for resolveModelsPath. The 2 unrelated WikiRawMaterialDedupTest failures pre-date this commit and live in ba86bea. |
||
|---|---|---|
| .. | ||
| src | ||
| Dockerfile | ||
| pom.xml | ||