olivier/claude-failover
1
0
Fork 0
Code Issues Pull requests 3 Projects Releases Packages Wiki Activity Actions
claude-failover/WORK_IN_PROGRESS.md
Ubuntu 5cad53ac7a docs: add WORK_IN_PROGRESS.md and document false-positive protection 
- WORK_IN_PROGRESS.md captures the v0.2.1→v0.2.3 incident, root cause,
  and the optional follow-ups (preserve dedicated sessions during swap,
  Telegram alert on SwapRequested, /quota/status endpoint).
- architecture.md §2.2.1 describes the four-layer defense:
  strict patterns, 5xx veto, two-poll confirmation, post-swap cooldown.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-15 19:51:15 +00:00

3.6 KiB
Raw Blame History

Travaux en Cours - claude-failover

Dernière mise à jour

2026-04-15 19:30:00

Version Actuelle

0.2.3

Demande Actuelle

Aucune — v0.2.3 shippée, service stable.

Étapes Complétées

  • v0.2.1 — Cooldown post-swap + log forensique (trigger_session, pattern, snippet)
  • v0.2.2 — Confirmation 2-polls pour les hits sans reset time
  • v0.2.3 — Veto 5xx (api_error / overloaded_error / internal server error) et retrait du pattern générique "rate limit" (remplacé par rate_limit_error)
  • Documentation : docs/architecture.md §2.2.1 "False-positive protection"
  • Tests unitaires exhaustifs (14 cas pour isQuotaExhausted dont les 3 veto 5xx)
  • Déploiement prod : /usr/local/bin/claude-failover + service redémarré
  • Push sur Forgejo origin/main (commits 7c5f838 et 62e98cb)

Prochaines Étapes

  • Optionnel : préserver les sessions dédiées (ccl-1-conformvault, ccl-2-scanyze) lors d'un swap légitime — actuellement killAllPoolSessions les tue aussi. Interruption désagréable pour le travail interactif. Options : skip dedicated dans le kill, OU auto-relaunch avec --resume <uuid> après kill. Non-bloquant tant que les vrais quota hits sont rares.
  • Optionnel : telegram alert quand SwapRequested est émis pour que l'opérateur soit au courant sans lire les logs. Le notifier.Telegram existe déjà — il suffit de câbler.
  • Optionnel : exposer /quota/status via internal/api avec les champs last_swap_at, suspected_hit_at, cooldown_remaining pour le dashboard.

Contexte Important

  • Symptôme en prod (2026-04-15) : daemon faisait des swaps compte1↔compte2 en boucle (intervalle descendant à 1 min), tuant les sessions interactives ccl-1 et ccl-2 en permanence. reset="" sur tous les events.
  • Cause racine identifiée via le log forensique v0.2.1 : les 500 d'Anthropic contenaient le texte "rate limit" dans leur payload. Snippet capturé : API Error: 500 {"type":"error","error":{"type":"api_error",...}}. Le monitor les confondait avec de vrais 429.
  • Config reactivate_cooldown: "5m" existait déjà dans config.yaml mais n'était consommée que par le dispatcher — pas par le monitor. v0.2.1 a branché le monitor dessus.
  • Comptes disponibles : compte1 (Claude Max), compte2 (Claude Team). Symlink actuel : ~/.claude → .claude-compte2.
  • Sessions tmux gérées : pool autonome ccl-auto-* (min=2, max=10) + dédiées ccl-1-conformvault, ccl-2-scanyze.

Fichiers Modifiés (cette série de fixes)

  • internal/quota/monitor.go — quotaPatterns, serverErrorPatterns, suspectedHitAt, cooldown
  • internal/quota/monitor_test.go — 14 sous-tests isQuotaExhausted + 3 tests poll
  • internal/state/state.go — LastSwapAt/From/To + RecordSwap + LastSwapInfo
  • internal/switcher/account_switcher.go — appel state.RecordSwap() après swap
  • docs/architecture.md — §2.2.1 False-positive protection
  • VERSION.md — changelog 0.2.1 → 0.2.3

Bugs Connus

  • Sessions dédiées tuées lors d'un swap légitime : comportement documenté et voulu (respawn sur le nouveau compte), mais coupe brutalement le travail interactif en cours. Voir Prochaines Étapes.

Historique des Demandes (Récentes)

Date Version Demande Status
2026-04-15 0.2.1 Casser le ping-pong + logs forensiques Terminé
2026-04-15 0.2.2 Confirmation 2-polls pour absorber les flashes Terminé
2026-04-15 0.2.3 Veto 5xx + patterns stricts (root cause) Terminé