KhiopsML
Replay scenario in batch mode with fast exit in case of errors
Contexte:
- pilotage de Khiops via des scénarios en mode batch
- en cas de scénario valide et d'exécution complète du scénario:
- on sort avec un exit code 0, et éventuellement des erreurs applicatives dans le log
- en cas de scénario invalide
- on sort avec un exit code 1, et une erreur fatale
fatal error : Command file : Batch mode failure
- on sort avec un exit code 1, et une erreur fatale
Problème:
- en cas de problème applicatif dans l'exécution du scénario (ex: problème de lecture d'un fichier dictionnaire):
- on a une erreur applicative
- mais en tentant de continuer l'exécution du scénario, on tente d'exécuter des lignes de scénario devenues invalides à cause du contexte d'exécution, et on sort en erreur fatale
Suggestion:
- lors de l'exécution d'un scénario en mode batch, on arrête dès qu'une erreur applicative est détectée
- on sort avec un exit code 0, avec dans le log la première erreur applicative détectée
- cela évite la sortie en fatal error, qui est plutôt réservée au cas d'un scénario vraiment invalide
- cela est suffisant en informant correctement l'utilisateur sur la nature de l'erreur
Suite à échanges avec Felipe.
Impacts
Cela va perturber de nombreux test existants de LearningTest
- exemple TestKhiops\SparseData\ReadWriteSparseFormatWrongKeys: lecture d'une dizaine de dictionnaire erronés
Evolution de la spécification
Il vaut mieux avoir un comportement dédié à un contexte d'utilisation
- possibilités
- uniquement sur option -j d'un json en entrée (cf issue https://github.com/KhiopsML/khiops/issues/230)
- semble le plus pertinent
- option supplémentaire sur la ligne de commande
- complexifie inutilement l'ensemble des options
- avoir une structure de contrôle de type EXIST_IF_ERRROR à insérer dans les scénarios aux endroits souhaités
- un peu laborieux
- uniquement sur option -j d'un json en entrée (cf issue https://github.com/KhiopsML/khiops/issues/230)
Autre question annexe
- gestion du mode API
- ce mode permet d'indiquer que les paths des fichiers sont à traiter tels quels, et non en relatif par au jeu de donnée comme de la GUI
- ce mode est actuellement piloté par la variable d'environnement KHIOPS_API_MODE (cf khiops_env.cmd)
- pourrait-il être activé quand on lance les scénario en mode batch par option -j?
- cela simplifierait le pilotage de Khiops
Bilan
Fonctionnalité en attente de maturation: attendre pour annuler ou lancer le développement
Suite à échange avec Stéphane
Intérêt de la fonctionnalité
Cette fonctionnalité est utile systématiquement dans tous les modes d'intégration (via des exécution de scenarios, pykhiops, AutoML, API...):
- cela permet de sortir avec une erreur utilisateur interprétable des qu'une ligne de scénario aboutit à une ou plusieurs erreurs utilisateur (Error...), avec un code retour à 0 de Khiops (sortie normale, mais erreurs utilisateur dans le log)
- cela évite des erreurs fatale (sortie en 1 de Khiops) du à des fins de scénario qui ne peuvent s'exécuter en raison d'un erreur en début de scénario (exemple: apprentissage non possible en raison d'un lecture préalable de dictionnaire erroné)
- c'est donc plus rapide et plus intelligible pour les utilisateurs
Problème pour les test de non-régression de LearningTest
Le seul cas qui pose problème est celui des test de non régression de LearningTest, qui fait réguliérement usage de scénario testant de nombreuses condition d'erreur (ex: CrashTest, avec une trentaine de cas d'erreur par tâche, scénarios avec lectures de nombreux dictionnaires erronés...). Il n'est cependant pas envisageable d'éclater les dizaines de jeux de test en des centaines de jeux de test plus atomiques, pour des raison de coût, de maintenabilité et d'utilisabilité.
Décision
- implémentation du mode fast-exist en cas d'erreur utilisateur pour l'exécution des scénarios
- mise en place d'un mode caché pour garder le comportement actuel, uniquement pour les LearningTest
- variable d'environnement KhiopsFastExitMode non documentée (gérée de façon similaire à KhiopsCrashTestMode)
- traiter comme true par defaut, si non renseignée
- positionnée à false dans les scripts de LearningTestTool, pour garder le comportement actuel pour les tests de non régression
Le commentaire de l'issue #216 suggère de nettoyer le code lors de la suppression du code retour 2. Il est probable qu'on ai besoin d'avoir accès au compteur des erreurs applicatives pour cette issue. On décidera à ce moment là si le nettoyage est nécéssaire.
