You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
virtualModelRoutable (packages/backend/src/routing/virtual-models/virtual-model-chain.ts, entrou no #190) diz routable: true para um virtual cujas rotas pertencem a um provedor desconectado do agente.
chainContextWindow só descarta rotas unavailable, e snapshotRouteState devolve unknown quando a conexão não tem modelos no snapshot, que é exatamente o caso de um provedor removido ou desabilitado para o agente.
Cenário
Crie um virtual só com rotas deepseek/*.
Desconecte o DeepSeek do agente, mantendo outro provedor (para não cair em no_provider).
Resultado:
routing virtual list mostra routable: true;
thinker routing status e thinker_routing_status mostram routes_by_virtual_model: true e incluem o virtual em active_virtual_models;
o proxy (isRouteAvailable, fallback de registros em provider-key.service.ts:~435-446) devolve false e o pedido termina em M301.
O impacto é só no status informativo do MCP, da CLI e da listagem. O roteamento está correto.
Tratar unknown como o fallback de isRouteAvailable faz: a rota só conta se o provedor tem registro ativo para o agente. Carregar os provedores uma vez em toViews. A descoberta fria continua contando. Alternativa: routable tri-state.
Falta teste para "provedor desconectado". O teste "routes all gone" só cobre um modelo sumido de um provedor que continua conectado.
Activity