When a legitimate quota hit triggered a swap, killAllPoolSessions tore down the dedicated interactive sessions (ccl-1-conformvault, ccl-2-scanyze) along with the pool, then recreatePoolSessions re-opened them at a bare bash prompt. The operator had to manually re-run CLAUDE_CONFIG_DIR=<target> claude --dangerously-skip-permissions --resume <uuid> after every swap, losing whatever conversation was mid-flight. saveAllSessions only iterates sessions tracked as "working" in state; user-driven dedicated sessions are rarely in that state so their resume UUIDs were never saved. - saveDedicatedUUIDs: capture resume UUID for every configured dedicated session regardless of tracked state, before kill. - relaunchDedicatedSessions(targetHome): after recreate, send a resume command on each dedicated session pointing CLAUDE_CONFIG_DIR at the target account's home. Missing UUID → leave at shell, no blind launch. - isValidResumeUUID hardens against a corrupted resume-id.txt. New TestDedicatedRelaunchAfterSwap verifies end-to-end: pane capture → UUID persisted → resume command sent with the correct CLAUDE_CONFIG_DIR. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
7.3 KiB
7.3 KiB
Version actuelle : 0.3.0
[0.3.0] - 2026-04-15
Type: Minor — Auto-resume des sessions dédiées après un swap légitime
Corrigé
- Les sessions dédiées (ccl-1-conformvault, ccl-2-scanyze) étaient tuées puis
recréées au bash prompt lors d'un swap légitime (vrai 429 quota hit),
interrompant le travail interactif en cours. L'opérateur devait relancer
manuellement
claude --resume <uuid>avec le bonCLAUDE_CONFIG_DIRaprès chaque swap. - La couverture de
saveAllSessions()ne captait que les sessions tracked enstate="working". Les sessions dédiées user-driven étaient ignorées, donc leur UUID de resume était perdu au kill.
Ajouté
switcher.saveDedicatedUUIDs(): capture le UUID de chaque session dédiée configurée, peu importe son tracked state. Appelé juste avantkillAll.switcher.relaunchDedicatedSessions(targetHome): après recréation, envoieCLAUDE_CONFIG_DIR=<targetHome> claude --dangerously-skip-permissions --resume <uuid>dans chaque session dédiée. Si l'UUID manque, la session reste au shell (pas de tentative aveugle).isValidResumeUUID()défense contre un fichier resume-id corrompu (check longueur 36 + regex hex/dash).
Tests
- ✅
TestDedicatedRelaunchAfterSwapvérifie : capture UUID → write file → relaunch avec la bonne commande →CLAUDE_CONFIG_DIRpointant sur le home du compte cible. - ✅
go test ./...full suite
Fichiers modifiés
internal/switcher/account_switcher.gointernal/switcher/account_switcher_test.go
[0.2.3] - 2026-04-15
Type: Patch — Veto 5xx pour écarter les faux positifs persistants
Corrigé
- Les 500/503 d'Anthropic restent visibles dans l'historique de conversation
Claude Code (pas juste en flash). Donc
tmux capture-pane -S -3les voyait à chaque poll, et la confirmation 2-polls v0.2.2 finissait par les confirmer → swap sur faux positif persistant. - Racine du faux positif : le pattern
"rate limit"(substring lâche) matchait dans le contenu textuel d'un 500 rendu par Claude TUI.
Modifié
quotaPatternsretravaillés pour privilégier les signatures spécifiques :- Retiré :
"rate limit"(trop générique, matche les transcripts) - Ajouté :
"rate_limit_error"(type d'erreur Anthropic pour les vrais 429) - Ajouté :
"5-hour limit"(phrasing Claude Code)
- Retiré :
- Veto 5xx :
serverErrorPatterns= ["api_error","overloaded_error","internal server error","api error: 5"]. Si l'un est présent, même si unquotaPatternmatche,isQuotaExhaustedretournefalse. Un 500/503 n'est pas un quota.
Ajouté
hasServerError()helper + tests exhaustifs :api_error_500_veto,overloaded_error_veto,internal_server_error_vetoreal_rate_limit_error_wins(sanity : vrai 429 passe toujours)
Tests effectués
- ✅ 14 sous-tests
TestIsQuotaExhaustedpassent - ✅
go test ./...complet OK - ✅ Service redémarré
Fichiers modifiés
internal/quota/monitor.gointernal/quota/monitor_test.go
[0.2.2] - 2026-04-15
Type: Patch — Confirmation requise pour les faux positifs (root cause)
Corrigé
- Cause racine du ping-pong : les erreurs HTTP 500 transitoires d'Anthropic
contiennent le texte "rate limit" dans leur payload (
{"type":"api_error",...}avec des traces mentionnant "rate limit"). Le monitor les confondait avec de vrais 429 quota hits. La v0.2.1 cassait la boucle via cooldown, mais un swap par salve de 500s pouvait encore tuer les sessions dédiées. - Le nouveau log forensique v0.2.1 a révélé exactement ça (snippet capturé :
API Error: 500 {"type":"error","error":{"type":"api_error",...}).
Ajouté
- Confirmation 2-polls pour les hits sans reset time : si
extractResetTimene trouve rien (= pas un vrai 429), le monitor marque l'étatsuspectedHitAtet attend le poll suivant. Le swap n'est émis que si la détection persiste. Un hit isolé (= erreur 500 transitoire) est absorbé sans swap. - Un vrai 429 (avec
resets in 45 minutesouresets at 8pm) continue à déclencher un swap instantané. Monitor.suspectedHitAt(not locked — only touched from poll goroutine).- 3 nouveaux tests :
TestPollTriggersSwitchOnTwoBlockedPoolWithReset,TestPollRequiresConfirmationWhenNoResetTime,TestPollSuspectedHitClearedOnRecovery.
Tests effectués
- ✅
go test ./...— full suite passe - ✅ Service redémarré, état consistant
Fichiers modifiés
internal/quota/monitor.gointernal/quota/monitor_test.go
[0.2.1] - 2026-04-15
Type: Patch — Fix boucle de swaps infinis (ping-pong)
Corrigé
- Boucle infinie de swaps : le monitor pouvait émettre des
SwapRequestedtoutes les 30s, créant un ping-pong entre comptes quand du texte de pane (anciens errors Anthropic 500 / TUI banners) matchaitquotaPatternsavecreset="". En prod, interval observé descendant jusqu'à 1 min. - Cause racine : aucun cooldown global entre swaps dans la boucle de
détection. La config
quota.reactivate_cooldown(5m) existait mais n'était utilisée que par le dispatcher, pas par le monitor.
Ajouté
state.QuotaState.LastSwapAt/LastSwapFrom/LastSwapTo+RecordSwap()+LastSwapInfo()pour tracker le dernier swap.monitor.poll()vérifiequota.reactivate_cooldownavant de déclencher un swap. Log explicite quand le cooldown bloque :[quota] swap cooldown active.- Log forensique détaillé lors d'un
SwapRequested: session déclencheuse, pattern matché, snippet du pane (120 chars). Ex :trigger_session="ccl-1-conformvault" pattern="rate limit" snippet="...". switcher.executeSwitchappellestate.RecordSwap()aprèsSetActiveAccount.
Tests effectués
- ✅
go build ./cmd/claude-failoverOK - ✅
go test ./internal/quota/... ./internal/state/... ./internal/switcher/...OK - ✅ Binaire installé dans
/usr/local/bin/claude-failover - ✅ Service redémarré — pas de swap intempestif depuis
Fichiers modifiés
internal/state/state.gointernal/quota/monitor.gointernal/switcher/account_switcher.go
[0.2.0] - 2026-04-14
Type: Minor — Implémentation des goroutines Phase 2
Ajouté
- Phase 2.1 :
internal/watcher— SessionWatcher (détection fin de tâche, timeout, signal file) - Phase 2.5 :
internal/notify— Notifier Telegram + Resend email - Phase 2.2 :
internal/dispatcher— Dispatcher fsnotify + launchAgent - Phase 2.3 :
internal/quota— QuotaMonitor (scraping pane tmux) - Phase 2.4 :
internal/switcher— AccountSwitcher (state machine flip symlink) - Phase 2.6 :
internal/janitor— Janitor (housekeeping agent-queue) - Phase 2.7 :
cmd/claude-failover/main.go— Intégration complète toutes goroutines - Nouveaux champs config :
watcher,dispatcher,janitor,notifications state: ForEachWorking, SetStalled, SetActiveAccount, ActiveAccountconfig.example.yaml: sections complètes pour tous les composantsscripts/claude-failover.service: unité systemd
Tests effectués
- ✅ go test ./... -race (toutes phases)
[0.1.0] - 2026-04-14
Type: Initial — Daemon skeleton
Ajouté
- Entry point, signal handling, config YAML loader
- tmux.Client interface + ExecClient
- State struct (JSON flush, sessions)
- HTTP /health + /status
- SessionLifecycleManager (reconcile 15s)