fix(models): custom provider nodes lost their synced catalog after #9294 - #9691
Closed
diegosouzapw wants to merge 2 commits into
Closed
diegosouzapw wants to merge 2 commits into
diegosouzapw wants to merge 2 commits into
Conversation
getActiveSyncedCatalog filters by provider-named ACTIVE connections, but custom provider nodes (#7694 prefix proxies) live in provider_nodes — their 'provider' column carries the node TYPE, so the query never matches and the node's synced catalog silently resolves empty. That killed the #7694 effort-suffix resolution (<prefix>/<model>-high no longer stripped) and dropped supportedThinkingEfforts/limits for every custom node. Fix: when the provider-named query yields nothing but the storedProviderId itself addresses a catalog (<id>:<id> keys), fall back to it if a provider NODE with that id exists (nodes have no is_active flag — existing means active, deletion is the off switch). Validation (TDD): tests/unit/sync-reasoning-supported-efforts-7694.test.ts reproduced the break (2 failing: suffix not stripped, tier list undefined) and passes 23/23 with the fix.
Owner
Author
|
Fechado como dedup: a sessão /sweep-reds chegou à mesma regressão de forma independente e o commit |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug (produção)
O #9294 trocou a leitura do catálogo synced em
lookupModelMetaporgetActiveSyncedCatalog, que filtra por conexões ativas cujo campoprovider== providerId. Nodes custom (#7694 — proxies com prefixo) vivem emprovider_nodese o campoproviderdeles carrega o TIPO (openai-compatible), então a query nunca casa e o catálogo do node resolve vazio silenciosamente. Efeitos:<prefix>/<model>-highnão stripa mais para o modelo base).supportedThinkingEfforts/limites de TODO node custom somem da metadata de runtime.Fix
Fallback cirúrgico em
getActiveSyncedCatalog: quando a query por provider não retorna nada mas o própriostoredProviderIdendereça um catálogo (chaves<id>:<id>), usa-o se existir um provider NODE com esse id (getProviderNodeById— nodes não têm flagis_active: existir = ativo, deletar = desligar). A intenção do #9294 (excluir catálogos de conexões inativas de providers nomeados) fica intacta.Validação (TDD, Hard Rule #18)
tests/unit/sync-reasoning-supported-efforts-7694.test.tsreproduziu a quebra (2 failing: sufixo não stripado; tier listundefined) → 23/23 com o fix. Debug do caminho documentado: o mapa por conexão continha o catálogo, o filtro de conexões o descartava.