docs: cle Groq manquante depuis 2 mois (jamais reglee malgre diagnostic 01/07) + verification baserow-schema-mcp (faux positif, pas de bug)
This commit is contained in:
@@ -81,7 +81,7 @@
|
||||
| [Hermes Hub — Déploiement et Exploitation Multi-Univers sur VPS (FastAPI, proxy async, design tokens, Tailscale)](common/hermes-hub-deploiement.md) | 2026-08-19 | hermes, hub, multi-univers, vps, tailscale, cloudflare-access, fastapi |
|
||||
| [Migration cerveau Hermes DeepSeek V4 Flash → Mimo V2.5 (perso, HARNESS/dsh-vps, tt, nyora) — desynchro git/live, auth key_env cassee sur Bifrost, context_length/max_tokens recalibres. Suite 18/08 : straggler nyora-veille corrige + Tirith reste sur DeepSeek (exception assumee, decision Nabil)](common/migration-mimo-v25-cerveau-hermes.md) | 2026-08-17 -> 2026-08-18 | mimo, hermes, migration, bifrost, opencode-go, context-length, nyora-veille, tirith |
|
||||
| [Accès Bifrost (passerelle LLM, vision/OCR)](common/bifrost-access.md) | 2026-07-11 | bifrost, llm, x-bf-vk, bifrost-proxy, hermes-desktop |
|
||||
| [Bifrost — incidents VK & fallback (consolidé 23/06 + 06/07 + 11/07 + 02/09)](common/bifrost-vk-incidents.md) | 2026-09-02 | bifrost, vk, opencode, cout, governance |
|
||||
| [Bifrost — incidents VK & fallback (consolidé 23/06 + 06/07 + 11/07 + 02/09 + 03/09)](common/bifrost-vk-incidents.md) | 2026-09-02 | bifrost, vk, opencode, cout, governance |
|
||||
| [Migration provider → OpenCode Go (consolidé, état des modèles à jour)](common/opencode-go-migration.md) | 2026-09-02 | opencode, hermes, family-help |
|
||||
| [Résolution DNS dynamique nginx + piège troncature prefixe /api/](common/nginx-proxy-dns-resolution.md) | 2026-09-02 | nginx, proxy, docker, dns, redaction-pro |
|
||||
| [n8n Code nodes LLM vers Bifrost obligatoire](common/runbook-n8n-llm-bifrost.md) | 2026-06-15 | n8n, bifrost, code-node |
|
||||
|
||||
@@ -68,3 +68,13 @@ Le cache VK stale n'est plus un incident isole : 3 occurrences en 5 jours (23/06
|
||||
**Resultat** : whitelist nettoyee (retrait des 6 IDs fantomes/deprecies), `hy3` ajoute et confirme fonctionnel (~2-6s, gratuit), `mimo-v2.5` confirme fonctionnel pour redaction-pro (~40-45s, deja whiteliste par ailleurs).
|
||||
|
||||
**Backup pris avant toute modification** : `config.db.bak-redaction-pro-models-20260902-163248`.
|
||||
|
||||
## Suite 03/09/2026 — clé Groq réellement manquante depuis 01/07, jamais posée
|
||||
|
||||
Le commit `f52b2b5` du 01/07 titré "fix: Groq provider Bifrost (cle manquante)" n'a en réalité RIEN corrigé côté Bifrost — seuls des chips morts (Gemma GAS, doublon OR) ont été retirés de `index.html`, les 4 chips Groq (dont 2 avec des noms de modèles déjà décommissionnés côté Groq) sont restés en place. Vérifié le 03/09 : `config_keys` ne contenait AUCUNE ligne pour `provider_id=82` (groq) — provider enregistré dans `config_providers` mais jamais de clé associée. Deux mois d'indisponibilité silencieuse.
|
||||
|
||||
**Fix definitif** : clé Groq récupérée depuis l'environnement d'un conteneur `hermes-agent-*` (`docker exec <container> env | grep GROQ_API_KEY` — la clé est injectée aux 3 instances Hermes via `docker-compose.yml` top-level, `${HERMES_*_GROQ_KEY}`), testée en direct sur `api.groq.com` avant d'être ajoutée. INSERT dans `config_keys` (provider_id=82) + `governance_virtual_key_provider_configs` (allow_all_keys=1) pour la VK redaction-pro. Restart bifrost obligatoire (même piège que d'habitude).
|
||||
|
||||
**Modèles Groq réellement valides sur ce compte** (vérifié via `GET https://api.groq.com/openai/v1/models`) : `openai/gpt-oss-120b` et `openai/gpt-oss-20b` uniquement — ultra-rapides (~0.15-0.3s). `llama-3.3-70b-versatile` et `meta-llama/llama-4-scout-17b-16e-instruct` (les deux autres chips historiques de redaction-pro) **n'existent plus du tout** dans le catalogue Groq — décommissionnés côté fournisseur, pas un problème de config. Retirés de `index.html`.
|
||||
|
||||
**Leçon** : un titre de commit "fix: X (cause identifiée)" ne garantit pas que X a été corrigé — toujours vérifier le diff réel, pas juste le message. Ici le diagnostic était juste mais l'action corrective a été oubliée en route.
|
||||
|
||||
@@ -113,5 +113,13 @@ Valider avec `docker exec <proxy> nginx -t` puis `nginx -s reload` (pas besoin d
|
||||
| Service Proxy | Statut prefixe non-racine |
|
||||
|---|---|
|
||||
| `redaction-pro` (`/api/`) | ✅ Bug trouve et corrige le 02/09/2026 (rewrite ajoute) |
|
||||
| `baserow-schema-mcp` (`/mcp/`) | ⚠️ A verifier — meme pattern a risque, non audite |
|
||||
| `baserow-schema-mcp` (`/mcp/`) | ✅ Verifie 03/09 — pas un bug, backend attend le prefixe complet (voir addendum) |
|
||||
| `baserow-oauth-proxy` | OK — utilise `$upstream$request_uri` (chemin complet volontaire), pas concerne |
|
||||
|
||||
## Vérification 03/09/2026 — baserow-schema-mcp exclu du périmètre (faux positif)
|
||||
|
||||
Le pattern `location /mcp/ { proxy_pass $mcp_upstream; }` (sans rewrite ni `$request_uri`) ressemble au bug corrigé sur redaction-pro, mais **ce n'en est PAS un ici**. Vérifié dans `app/main.py` : le serveur mcp.server.fastmcp lui-même monte ses routes sous `Mount(f"/mcp/{MCP_SECRET_TOKEN}", app=mcp.sse_app())` — le backend attend explicitement le chemin complet avec le préfixe `/mcp/<token>/...`. Transmettre l'URI non tronquée (comportement par défaut de `proxy_pass` avec variable) est donc ici le comportement CORRECT et nécessaire, pas un bug.
|
||||
|
||||
Testé bout-en-bout via le domaine public (`GET /mcp/<token>/sse`) : 200 OK, event-stream valide avec endpoint de session retourné. Aucune action requise sur ce service.
|
||||
|
||||
**Règle affinée** : le pattern à risque décrit plus haut ne s'applique que si le backend attend un chemin SANS le préfixe du `location`. Toujours vérifier le montage réel du backend (code source ou test direct sur le port interne, avec et sans préfixe) avant de conclure à un bug — ne pas généraliser depuis la seule forme de la config nginx.
|
||||
|
||||
Reference in New Issue
Block a user