[BACK] new structure for errors detected exported in jsonl

[Mankouri]

• Remplacement du format d’erreurs errors.json par un format JSON Lines (errors.jsonl) plus structuré et exploitable.
• Chaque erreur comporte désormais: timestamp, code, message, fichier concerné, étape, etc.
• Centralisation de la gestion des erreurs via la méthode _log_error.
• Génération du fichier errors.jsonl à la fin du pipeline, prêt à être consommé par le front ou des outils BI.

Champs présents dans chaque erreur :

timestamp - string - Date et heure UTC de l’erreur (format ISO 8601, ex : "2025-05-28T15:00:00Z")
error_code - string - Code unique pour le type d’erreur (ex : "FORMAT_NOT_SUPPORTED", "LOAD_FAILED")
message - string -Message lisible décrivant l’erreur
file_url - string - URL ou chemin du fichier concerné (si applicable)
dataset - string - Nom du dataset ou du workflow concerné
step - string - Étape du pipeline où l’erreur est survenue (ex : "process_files", "download_file")
details - objet - Détails techniques additionnels (ex : titre du fichier, exception, etc.)

Exemple d’une ligne :
{"timestamp":"2025-05-28T15:00:00Z","error_code":"FORMAT_NOT_SUPPORTED","message":"Format xls not supported","file_url":"https://example.com/file.xls","dataset":"subventions","step":"process_files","details":{"title":"Budget 2024"}}

Objectifs:

• Faciliter l’exploitation et la visualisation des erreurs côté front.
• Améliorer la traçabilité et le debug des workflows de données.

Si besoin on peut changer la structure assez aisément (même le format de fichier en sortie ;) )

PS: En draft car il faut que je test encore

[RiwsPy]

C'est une très bonne idée de passer par du jsonl pour pouvoir gérer/filtrer une grande quantité de log.

Je m'interroge sur la pertinence de recréer un système de log indépendant du premier.
Le logger de base pourrait être formaté pour accepter deux sorties : une "traditionnelle" et une autre jsonl ?
On aurait une seule ligne de code pour générer les deux logs et ça pourrait être mis en place de façon automatique pour tous les appels du projet sans avoir à modifier le code (il sera nécessaire de le faire pour profiter pleinement des nouveaux paramètres mais ça fonctionnerait sans).
Sans compter les attributs utiles des LogRecord comme funcName qui pourrait être l'équivalent de step ou le format timestamp commun à tout le projet.

Bref, je veux bien que tu m'expliques pourquoi on utilise pas un logger pour créer ce errors.jsonl ?

[Mankouri]

Merci pour ton retour ! J'ai en effet hésité à faire coexister l'existant et la nouvelle version. J'avais volontairement séparé le errors.jsonl du logger principal pour ne pas polluer les logs et permettre une structure fixe exploitable par le front rapidement implémentable dans un premier temps pour ensuite raccorder tout ça à un Logger propre sans re écrire les workflows.

Je vais faire en sorte que l'on ai les deux versions (ancienne ".json" et nouvelle ".jsonl") et intégrer la nouvelle version avec le Logger directement dans cette MR :).