Improve Launcher Job to integrate Unarchiving Job

[laurent-laporte-pro]

Problem Statement

Lorsqu'un job de lancement de simulation d'étude est terminé, la date de fin completion_date est mise à jour. Les utilisateurs de l'API utilisent le endpoint /v1/launcher/jobs/{job_id} pour récupérer l'état du job et lisent l'attribut completion_date pour déterminer si le job est terminé (la valeur est non nulle) ou non et aussi pour déterminer si les sorties sont disponibles.

Or, une seconde tâche est lancée pour décompresser les sorties. Cette tâche est asynchrone, et donc l'utilisateur pense que les sorties sont décompressées alors que ce n'est pas toujours le cas au moment de l'utilisation du endpoint.

Dans le gestionnaire des tâches, on voit bien une tâche pour la simulation et une tâche pour le désarchivage :

Proposed Solution

Dans l'idéal, il ne faudrait qu'un seul job qui engloberait à la fois la simulation et le désarchivage des sorties. Ainsi, l'attribut completion_date correspondrait bien à une mise à disposition complète des sorties.

Remarques :

• Lorsque le désarchivage est terminé, le fichier ZIP est automatiquement supprimé (pour libérer de la place).
• À vérifier : l'API de lecture des sorties doit permettre la lecture des données directement dans le fichier ZIP. Cependant, cette fonctionnalité ne doit pas exister pour lire des matrices. Il y a aussi un risque à lire un fichier ZIP si celui-ci est sur le point d'être supprimé.
• L’ID de la tâche de désarchivage n'est pas connu à l’avance. Autrement dit, l'utilisateur ne peut pas utiliser cette information pour savoir si les sorties sont bien désarchivées.
• Le désarchivage automatique peut être désactivé lors du lancement d'une simulation, via l'option "Auto unzip".

Estimation de la complexité : la fusion de deux jobs est une opération jugée complexe.

Workaround

La solution de contournement consiste à récupérer le nom et l'ID de l'étude et de rechercher dans la liste des tâches, la tâche de désarchivage qui concerne cette étude. Pour ce faire, le endpoint à utiliser est POST /v1/tasks avec le payload suivant:

{"type": ["UNARCHIVE"], "name": "Unarchive output {study_name}/{output_id} (study_id)"}

Cela permet de récupérer la liste des tâches qui correspondent. Si cette liste est vide, le désarchivage n'a pas encore commencé. Sinon, la liste contient une unique tâche: la lecture de l'attribut status permet de savoir si la tâche de désarchivage est terminée (dans ce cas, status == 3).

Remarque Martin:
Après avoir vu avec Alexander, ce workaround ne peut être effectué qu'en étant connecté avec le compte admin. En effet, le endpoint POST /v1/tasks ne renvoie que les tâches appartenant à l'user qui utilise l'endpoint. Hors cette tâche appartient toujours à l'admin 😕