Dépannage

Kisenon est en alpha. Voici les modes de défaillance que vous êtes le plus susceptible de rencontrer, et comment dépasser chacun.

Endpoint coincé dans Pending

Symptôme : un endpoint reste dans Pending plus de quelques secondes à la création. La console n'affiche aucune erreur ; la CLI affiche le même état.

Cause probable : le pod de calcul ne peut pas être planifié. Les raisons les plus courantes sont la pression du cluster (aucun nœud n'a le CPU ou la mémoire demandés disponibles) ou un identifiant de pull d'image périmé. Les deux sont des problèmes côté opérateur.

Que faire :

1. Attendez 60 secondes. La pression transitoire se résorbe généralement dès qu'un autre endpoint se suspend.
2. Si cela ne se résorbe pas, supprimez l'endpoint et recréez-le. Le plan de contrôle réessaiera la planification sur un autre nœud.
3. Si la recréation atterrit aussi dans Pending, le cluster est mécontent. Déposez un rapport sur le tracker GitHub avec l'id de l'endpoint et l'heure murale.

FATAL: endpoint unavailable à la première connexion

Symptôme : psql renvoie FATAL: endpoint unavailable à la toute première connexion à un endpoint fraîchement créé, ou après une longue inactivité.

Cause probable : course au démarrage à froid. L'état de l'endpoint est Stopped, votre paquet l'a réveillé, mais Postgres rejoue encore le WAL jusqu'au HEAD de la branche quand votre client abandonne.

Que faire : réessayez la connexion. Le démarrage à froid se termine généralement en 300 à 500 ms, mais le tout premier réveil d'un projet fraîchement créé, ou après une inactivité de 24 h+, peut prendre de 10 à 30 secondes pendant que le cache de pages du pageserver se réchauffe. La plupart des drivers tolèrent cela si vous autorisez au moins un réessai ; psql brut ne réessaie pas par défaut.

# psql with one explicit retry
for i in 1 2; do psql "$URI" -c '\q' && break; sleep 5; done

Si l'endpoint est toujours indisponible après 30 secondes, le pod lui-même peut avoir échoué — vérifiez l'état dans la console et consultez les conseils sur Pending ci-dessus.

keon connection-string renvoie branch_not_found

Symptôme :

$ keon connection-string my-feature --project prj_abc...
Error: branch_not_found: my-feature

…mais la branche existe dans la console.

Cause probable : le nom ne correspond pas à une branche dans le projet que vous avez ciblé — généralement une faute de frappe, ou le mauvais --project. La CLI résout une branche par id ou par nom, que vous le passiez comme argument positionnel ou via --branch, donc un nom qui existe bien se résoudra dans les deux cas.

Que faire : confirmez le nom de la branche et le projet :

keon branches list --project prj_abc...
keon connection-string my-feature --project prj_abc...

La connexion renvoie access_denied

Symptôme : l'OAuth Google ou GitHub se termine, mais la console redirige vers une page d'erreur citant access_denied.

Cause probable : pendant l'alpha, la connexion est filtrée par une liste d'autorisation d'e-mails. Si votre adresse n'a pas été intégrée, le callback de connexion la rejette par principe.

Que faire : postulez à Accès alpha. Une fois votre adresse ajoutée à la liste d'autorisation, la connexion se termine normalement à la tentative suivante.

La session de la console expire en cours de session

Symptôme : la console fonctionne un moment, puis renvoie soudain des 401 sur chaque appel d'API jusqu'à ce que vous vous déconnectiez et vous reconnectiez.

Cause probable : le JWT signé par cp a expiré et sa fenêtre de rafraîchissement s'est écoulée. La console frappe un JWT de courte durée (≈15 minutes) et, pendant que vous êtes actif, le rafraîchit en arrière-plan contre /v1/auth/refresh. La fenêtre de rafraîchissement est fixée à 12 heures à compter de la connexion : une session active se renouvelle indéfiniment, mais un onglet laissé intact au-delà de cette fenêtre ne peut plus se rafraîchir.

Que faire : déconnectez-vous et reconnectez-vous. Pour l'automatisation sans tête ou de longue durée, utilisez une clé API nsk_ plutôt qu'une session de navigateur — les clés API n'expirent pas et sont révoquées explicitement. Voir Authentification.

Où déposer les bugs

Pour tout ce qui n'est pas couvert ici :

• Bugs produit et demandes de fonctionnalités : le tracker GitHub.
• Vulnérabilités de sécurité : Sécurité — jamais sur le tracker public.

Des étapes de reproduction concrètes, les ids affectés (projet, branche, endpoint) et un horodatage murale raccourcissent considérablement l'aller-retour.