- Shipped
- 30 Agosti 2026, 00:27 UTC
- Author
- Kamo
- Commit
- 91cc304
Follow-up to the router-catalogue fix. That stops unroutable models being LISTED; this stops one already in an org's catalogue from breaking the assistant and narrating the breakage. Two things went wrong once a stale row existed. Adapters failed with RuntimeException(status + " from HuggingFace: " + rawBody), and both transports put getMessage() straight in front of the member — so the chat window showed another vendor's name, a model identifier the member never chose, and nothing they could act on. And nothing retired the row, so every message afterwards hit the same wall with the settings screen still looking fine. - AiProviderException carries a member-safe message beside the raw detail; memberTextFor() leaves Kamo's own errors alone, since those are already written for a person. The raw body still goes to the log, which is where it is diagnostic. - The HuggingFace adapter classifies a refusal: model_not_supported is the one failure that is neither transient nor the member's. - ChatOrchestrationService deactivates that model, beside the existing auth-failure handling. Best-effort and never rethrown — it runs inside an error handler and must not replace the error already on its way out. Auto routing and the picker both read is_active, so the org is left with the models that work.