Replay scenario in batch mode with fast exit in case of errors

marcboulle commented 4 months ago

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

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

marcboulle commented 4 months ago

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

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

marcboulle commented 4 months ago

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

bruno-at-orange commented 3 months ago

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.

marcboulle commented 3 months ago

Plutôt après le 10 juin

KhiopsML / khiops