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

[marcboulle]

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

[marcboulle]

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 #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]

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énario
• 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 pare 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]

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]

Plutôt après le 10 juin