fix(bifrost): correctif routage opencode-go casse (chemin /zen/go, pas le port) + raccordement hermes-tt/hermes-nabil/DSH au pattern bifrost-proxy
This commit is contained in:
@@ -10,6 +10,7 @@
|
||||
|
||||
| Runbook | Date | Tags |
|
||||
|---------|------|------|
|
||||
| [Correctif routage Bifrost -> OpenCode Go (base_url casse sur un residu de sidecar abandonne, chemin /zen/go sans /v1) + raccordement hermes-tt/hermes-nabil/DSH au pattern bifrost-proxy (creation vk-hermes-nabil, cloture volet routage du ticket infra-2026-09-023)](common/bifrost-opencode-routing-fix-20260907.md) | 2026-09-07 | infra, bifrost, opencode-go, hermes-tt, hermes-nabil, dsh, virtual-key, routing |
|
||||
| [Piège clé virtuelle Nabil-Key (bfk-0cd1fb...) vs clés dédiées Hermes : fuite budgétaire 8 $/mois, audit exhaustif (perso/tt/nyora), correction chirurgicale vision perso, et tests d'inférence réels (ticket infra-2026-09-014)](common/piege-virtual-key-nabil-key-bifrost-hermes-20260904.md) | 2026-09-04 | infra, bifrost, virtual-key, nabil-key, budget, hermes, audit, gemini |
|
||||
| [Architecture stub forwarder Bifrost (NAS -> VPS via socat/SOCKS5 tailscale-nyora-bridge:1055), procédure de rollback immédiat (<5s), piège allow_all_keys / config.json au boot, et injection session x-bf-eh-x-opencode-session sur bifrost-proxy (tickets infra-2026-09-010 et 008)](common/migration-vps-bifrost-stub-forwarder-20260904.md) | 2026-09-04 | infra, bifrost, vps, tailscale, socat, rollback, allow-all-keys, opencode-go |
|
||||
| [Decommission veille-backend/veille-frontend (API FastAPI) au profit d une page statique bolbol.tn/veille (localStorage, tags, recherche, lu/non lu) ; workflow n8n Ingest Opportunites desactive (cible supprimee)](common/veille-decommission-api-page-statique-20260904.md) | 2026-09-04 | veille, veille-nexum, decommission, page-statique, localstorage, n8n, ports-registry |
|
||||
@@ -80,6 +81,7 @@
|
||||
|
||||
| Runbook | Date | Tags |
|
||||
|---------|------|------|
|
||||
| [Correctif routage Bifrost -> OpenCode Go (base_url casse sur un residu de sidecar abandonne, chemin /zen/go sans /v1) + raccordement hermes-tt/hermes-nabil/DSH au pattern bifrost-proxy (creation vk-hermes-nabil, cloture volet routage du ticket infra-2026-09-023)](common/bifrost-opencode-routing-fix-20260907.md) | 2026-09-07 | infra, bifrost, opencode-go, hermes-tt, hermes-nabil, dsh, virtual-key, routing |
|
||||
| [Piège clé virtuelle Nabil-Key (bfk-0cd1fb...) vs clés dédiées Hermes : fuite budgétaire 8 $/mois, audit exhaustif (perso/tt/nyora), correction chirurgicale vision perso, et tests d'inférence réels (ticket infra-2026-09-014)](common/piege-virtual-key-nabil-key-bifrost-hermes-20260904.md) | 2026-09-04 | infra, bifrost, virtual-key, nabil-key, budget, hermes, audit, gemini |
|
||||
| [Passerelle MCP dédiée NyoraNotes (multi-agent, StreamableHTTP port 3098, scoping strict par dossier, connecteur DSH validé)](common/nyora-notes-mcp-gateway-deploiement-20260826.md) | 2026-08-26 | nyora-notes-mcp, mcp, streamable-http, scoping, dsh, tailscale |
|
||||
| [Réduction hermes-hub en dispatcher minimal & stabilisation DSH (historique, WebSockets, mémoire NyoraNotes)](common/decommission-switcher-hub-stabilisation-dsh-20260826.md) | 2026-08-26 | dsh, hermes-hub, dispatcher, websocket, history-fix, nyora-notes |
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
# Correctif routage Bifrost -> OpenCode Go & raccordement hermes-tt/hermes-nabil/DSH (07/09/2026)
|
||||
|
||||
## 1. Contexte
|
||||
|
||||
Le 07/09/2026, Nabil (au travail, sans acces Gemini) signale trois pannes simultanees :
|
||||
- **hermes-tt** et **hermes-nabil** : "provider failed after retries"
|
||||
- **hermes-nyora** : bascule silencieuse sur le modele de secours (deepseek-v4-flash via opencode-go -> openrouter)
|
||||
- **DSH** : `400 MissingSessionID` a chaque tour
|
||||
|
||||
Diagnostic mene et corrige en direct par Claude (intervention SMART justifiee par l'absence de Gemini, cf. hermes-platform.md).
|
||||
|
||||
## 2. Cause racine n°1 : chemin cassé sur le provider `opencode` de Bifrost
|
||||
|
||||
`config.json` de Bifrost (`providers.opencode.network_config.base_url`) pointait vers `http://opencode-proxy:8080/zen/go`.
|
||||
|
||||
Ce chemin est un residu de la tentative de sidecar local du 04/09/2026, **deja abandonnee** a l'epoque a cause du validateur SSRF interne de Bifrost qui bloque toute IP privee (voir `migration-vps-bifrost-stub-forwarder-20260904.md`, section 5). En plus d'etre la mauvaise approche, la valeur etait meme cassee techniquement : `opencode-proxy` (VPS) n'ecoute reellement que sur le port 8902, pas 8080 -> connexion refusee a chaque appel.
|
||||
|
||||
Consequence : tout appel `provider=opencode` via Bifrost echouait systematiquement. hermes-nyora/perso (qui ont un fallback configure) basculaient silencieusement sur un modele degrade sans que Nabil s'en rende compte immediatement ; hermes-tt (sans fallback) et tout consommateur direct echouaient dur.
|
||||
|
||||
### Correctif applique
|
||||
Retour a la solution native documentee le 04/09 (relais d'en-tete `x-bf-eh-x-opencode-session` par `bifrost-proxy`, pas de sidecar) :
|
||||
```
|
||||
base_url: https://opencode.ai/zen/go
|
||||
```
|
||||
Attention : **pas de `/v1` a la fin**. Bifrost ajoute lui-meme `/v1/chat/completions` sur les providers OpenAI-compatibles ; un `base_url` finissant deja par `/v1` produit un double `/v1` et une 404 HTML (page opencode.ai, pas une erreur JSON API) — piege facile a mal diagnostiquer.
|
||||
|
||||
### Procedure
|
||||
```bash
|
||||
# Sur le VPS, dans le conteneur bifrost (root)
|
||||
docker exec -u 0 bifrost sh -c "cp /app/data/config.json /app/data/config.json.bak-<date>"
|
||||
docker exec -u 0 bifrost sh -c "sed -i 's#ANCIENNE_VALEUR#https://opencode.ai/zen/go#' /app/data/config.json"
|
||||
# Valider le JSON avant de redemarrer (le conteneur bifrost n'a ni python3 ni node)
|
||||
docker run --rm -v /home/dsh-agent/bifrost/data:/data:ro alpine:3.20 sh -c 'apk add -q jq; jq empty /data/config.json && echo VALID_JSON'
|
||||
docker restart bifrost
|
||||
```
|
||||
|
||||
### Test de validation (depuis le NAS, via bifrost-proxy)
|
||||
```bash
|
||||
curl -s -X POST http://localhost:3086/v1/chat/completions \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer <VIRTUAL_KEY>" \
|
||||
-d '{"model":"opencode/mimo-v2.5","messages":[{"role":"user","content":"ping"}],"max_tokens":10}'
|
||||
```
|
||||
Une reponse JSON `chat.completion` valide confirme le bon fonctionnement (teste avec succes pour vk-hermes-nyora, vk-hermes-perso, vk-hermes-tt, vk-hermes-nabil, vk-dsh-vps le 07/09/2026).
|
||||
|
||||
## 3. Cause racine n°2 : hermes-tt, hermes-nabil et DSH jamais raccordes au pattern bifrost-proxy
|
||||
|
||||
Ces trois consommateurs appelaient OpenCode Go **en direct** (`https://opencode.ai/zen/go/v1` ou provider `opencode-go`/`opencode-direct` sans passer par `bifrost-proxy`), donc sans l'injection de `x-opencode-session` -> `MissingSessionID` systematique, sans le filet de securite qu'offre Bifrost (fallback, tracking cout, whitelist par cle).
|
||||
|
||||
### hermes-tt (NAS, `hermes-agent-tt`, /opt/data/config.yaml)
|
||||
Avant :
|
||||
```yaml
|
||||
model:
|
||||
provider: opencode-go
|
||||
base_url: ''
|
||||
api_key: ''
|
||||
fallback_providers: []
|
||||
```
|
||||
Apres (aligne sur hermes-nyora/perso) :
|
||||
```yaml
|
||||
model:
|
||||
provider: custom
|
||||
base_url: http://bifrost-proxy/v1
|
||||
api_key: sk-bf-26694aba-54d0-4d03-8c4c-a6e3830b6cbe # vk-hermes-tt (existait deja depuis le 18/07, jamais utilisee)
|
||||
fallback_providers:
|
||||
- provider: opencode-go
|
||||
model: mimo-v2.5
|
||||
key_env: OPENCODE_GO_API_KEY
|
||||
```
|
||||
|
||||
### hermes-nabil (VPS, /data/config.yaml)
|
||||
Avant : `base_url: https://opencode.ai/zen/go/v1`, cle OpenCode Go brute.
|
||||
Apres :
|
||||
```yaml
|
||||
model:
|
||||
provider: custom
|
||||
base_url: http://100.86.197.88:3086/v1 # IP Tailscale du NAS, port publie de bifrost-proxy (le hostname docker "bifrost-proxy" n'existe que sur le reseau n8n du NAS, injoignable depuis le VPS)
|
||||
api_key: sk-bf-eb2e9179-c646-4e84-afe7-bc7c61b16f59 # vk-hermes-nabil, creee le 07/09/2026
|
||||
```
|
||||
**Nouvelle cle virtuelle creee** via l'API Bifrost (`POST /api/governance/virtual-keys` sur `localhost:3085`, meme structure `provider_configs` que vk-hermes-perso : google/groq/nvidia_nim/opencode/openrouter). Piege confirme une fois de plus (voir migration-vps-bifrost-stub-forwarder-20260904.md section 4) : l'API cree la cle avec `allow_all_keys=false` malgre le payload envoye a `true` — patch SQL obligatoire puis restart :
|
||||
```sql
|
||||
UPDATE governance_virtual_key_provider_configs SET allow_all_keys=1 WHERE virtual_key_id='<id>';
|
||||
```
|
||||
|
||||
### DSH (VPS, /home/dsh-agent/.dsh/settings.yaml)
|
||||
Cas different : le provider `bifrost` etait **deja correctement configure** (baseURL `http://100.86.197.88:3086/v1`, `BIFROST_API_KEY` = vk-dsh-vps deja valide cote Bifrost) mais `agent-default-model.provider` restait sur `opencode-direct`. Il manquait aussi l'entree `opencode/mimo-v2.5` dans le catalogue de modeles du provider bifrost (seuls deepseek-v4-flash/gemini/gemma/qwen y figuraient).
|
||||
Correctif : bascule de `provider: opencode-direct` -> `provider: bifrost`, `model: mimo-v2.5` -> `model: opencode/mimo-v2.5`, ajout de l'entree modele manquante.
|
||||
|
||||
## 4. Perimetre restant (non traite dans cette session)
|
||||
|
||||
Le volet nyora-doc-api/nyora-convert-api du ticket infra-2026-09-023 (bascule des appels NAS vers les instances VPS pour tous les assistants) n'a pas ete traite ici — uniquement le volet routage LLM/Bifrost.
|
||||
|
||||
## 5. Lecon a capitaliser
|
||||
|
||||
Ne jamais faire confiance a un `base_url` existant dans `config.json` sans verifier qu'il correspond a une architecture **actuellement valide** — un residu d'une tentative abandonnee (meme documentee comme abandonnee ailleurs) peut rester en config sans lever d'alerte jusqu'a ce qu'un consommateur sans fallback tombe dessus. Toujours re-tester en conditions reelles (requete complete, pas juste `/health`) apres toute correction de routage LLM.
|
||||
Reference in New Issue
Block a user