7d68605e83
Sylvain a rapporté un errorcode 104 en testant l'envoi. Le code vient du protocole PFTP de Polar, et pftp_error.proto du SDK officiel le nomme : 104 = DIRECTORY_EXISTS. Ce n'est donc pas un refus de la montre — la session BLE s'était parfaitement ouverte, le transport fonctionnait, et c'est notre séquence de mkdir qui n'était pas idempotente. L'hypothèse fautive était écrite noir sur blanc dans parseSteps : « aucun des deux n'existe d'avance pour une date neuve ». Vrai d'une date neuve, faux dès le second envoi vers la même date — exactement ce que Sylvain venait de faire après avoir réussi un premier envoi. Un mkdir qui bute sur 104 est désormais considéré comme satisfait, à la manière d'un mkdir -p : le dossier est là, c'est tout ce qu'on lui demandait. Strictement limité à la création de dossier — un put de fichier n'est jamais avalé, 105 FILE_EXISTS signifierait que l'objectif est déjà écrit et l'appelant doit le savoir. Le renvoi n'est pas passé sous silence pour autant : ecrire() rend un drapeau dossierPreexistant, le plugin le résout en alreadyExisted, et l'UI de coach affiche « Un objectif existait déjà à cette date. Redémarrer la montre pour que le nouveau s'affiche. » C'est la contrepartie de l'index en cache constaté le 31/08 — sans cet avertissement, l'envoi annoncerait un succès que la montre ne montrerait pas. Les codes PFTP sont définis dans PolarPftpStep.swift, donc couverts par les tests Linux : 87 tests verts, dont 3 nouveaux qui vérifient que 104 est satisfaisant pour un mkdir et que 103, 105, 106 et 108 restent des échecs. ⚠️ CoachPolarBLE.swift n'est pas compilable ici — Capacitor et le SDK Polar n'existent pas sur Linux. La modification du plugin est à vérifier au prochain build Xcode ; la logique des codes, elle, est testée. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
14 KiB
14 KiB