[P1][audio] Nettoyer la capture live après une erreur STT pendant stop #56

New issue

Closed

opened 2026-09-29 20:34:48 +00:00 by silex · 0 comments

silex commented

2026-09-29 20:34:48 +00:00

Owner

Gravité et périmètre

P1 / high. Capture live, confidentialité et cycle de vie audio. Revue du commit 65442d2.

Constat

Un dépassement de budget STT pendant le drainage après stop termine la session en failed, sans livraison, mais laisse la capture et des segments WAV dans le runtime même lorsque la rétention est désactivée.

Le chemin internal/session/orchestrator.go:395–402 appelle recording.Abort() puis retourne sans finishLiveCapture. Dans le recorder de production, internal/audio/pwrecord/live.go:262–280, un Abort arrivé après la prise de possession par Stop attend simplement la fin et ne nettoie pas. Le FakeRecorder nettoie ce même cas : le test existant ne révèle donc pas le défaut.

Reproduction

Dans une copie du dépôt : assembler l'orchestrateur avec pwrecord.New et un FakeExecutor simulant uniquement le processus pw-record ; fournir cinq secondes de PCM, bloquer le premier appel STT, demander stop, attendre SIGINT, puis libérer une réponse de quatre octets pour un budget de deux octets.

Trois répétitions sous -race : résultat failed, capture recording.wav et au moins un segment encore présents avec rétention désactivée. Aucun microphone réel utilisé.

Impact

Conservation involontaire de données audio et accumulation de fichiers. Le parcours live est activé par défaut, mais le déclencheur reproduit exige un dépassement de limite STT pendant l'arrêt ; ce n'est pas un blocage systématique de l'usage.

Correction et acceptation

Garantir un nettoyage unique sur toutes les sorties de runLive, sans modifier la propriété Stop/Abort ni masquer l'erreur STT. Ajouter une régression utilisant le recorder de production et un processus simulé, vérifier les limites texte/segments, l'absence de fichiers résiduels lorsque Keep=false et l'absence de livraison. Conserver les contrôles succès et annulation.

## Gravité et périmètre P1 / high. Capture live, confidentialité et cycle de vie audio. Revue du commit `65442d2`. ## Constat Un dépassement de budget STT pendant le drainage après `stop` termine la session en `failed`, sans livraison, mais laisse la capture et des segments WAV dans le runtime même lorsque la rétention est désactivée. Le chemin `internal/session/orchestrator.go:395–402` appelle `recording.Abort()` puis retourne sans `finishLiveCapture`. Dans le recorder de production, `internal/audio/pwrecord/live.go:262–280`, un `Abort` arrivé après la prise de possession par `Stop` attend simplement la fin et ne nettoie pas. Le FakeRecorder nettoie ce même cas : le test existant ne révèle donc pas le défaut. ## Reproduction Dans une copie du dépôt : assembler l'orchestrateur avec `pwrecord.New` et un `FakeExecutor` simulant uniquement le processus pw-record ; fournir cinq secondes de PCM, bloquer le premier appel STT, demander stop, attendre SIGINT, puis libérer une réponse de quatre octets pour un budget de deux octets. Trois répétitions sous `-race` : résultat `failed`, capture `recording.wav` et au moins un segment encore présents avec rétention désactivée. Aucun microphone réel utilisé. ## Impact Conservation involontaire de données audio et accumulation de fichiers. Le parcours live est activé par défaut, mais le déclencheur reproduit exige un dépassement de limite STT pendant l'arrêt ; ce n'est pas un blocage systématique de l'usage. ## Correction et acceptation Garantir un nettoyage unique sur toutes les sorties de runLive, sans modifier la propriété Stop/Abort ni masquer l'erreur STT. Ajouter une régression utilisant le recorder de production et un processus simulé, vérifier les limites texte/segments, l'absence de fichiers résiduels lorsque Keep=false et l'absence de livraison. Conserver les contrôles succès et annulation.

silex added the

labels

2026-09-29 20:34:48 +00:00