Journal des modifications du moteur WDL pour HealthOmics

HealthOmics trims Windows-style (\r\n) termine les lignes de manière cohérente entreread_lines(), et read_tsv()read_map(), en fonction du comportement des outils Linux standard.

zip()cross(), et gérez read_tsv() désormais correctement les entrées de type mixte. Les solutions de contournement manuelles peuvent être supprimées.

Les fonctions intégrées zip()cross(), et read_tsv() maintenant déduisent correctement les types de leurs valeurs de retour. Dans les versions précédentes, ces fonctions pouvaient générer des erreurs de type inattendues lors de la combinaison de types mixtes (par exemple, Array[String] et Array[Int] lors d'un zip() appel), ce qui nécessitait des solutions manuelles de conversion de type dans le code WDL.

Si votre flux de travail inclut des transtypages explicites ajoutées pour contourner les erreurs de type provenant de zip() cross()read_tsv(), ou, vous pouvez les supprimer. HealthOmics déduit désormais automatiquement les types corrects.

Le maintien des transtypages existants ne provoquera aucune erreur et n'affectera pas le comportement du flux de travail.

basename(path, "")fix renvoie le nom du fichier au lieu d'une chaîne vide.

basename(path, "")renvoie maintenant le nom du fichier.

Par exemple, basename("/path/to/file.txt", "") retournera "file.txt" au lieu d'une chaîne vide.

Recherchez des basename(x, "") appels dans vos flux de travail. Le cas échéant, vérifiez que le renvoi du nom de fichier correspond au comportement attendu.

Float-key détection de collision dans collect_by_key()

collect_by_key()Floatles clés précédemment traitées comme identiques si elles correspondaient à 6 décimales. Des valeurs distinctes telles que 0.0000001 et 0.0000002 ont été fusionnées en un seul groupe.

À partir de la date de modification, HealthOmics détecte cette collision au moment de la création du flux de travail et fait échouer le flux de travail avec une erreur claire dans le champ GetWorkflow StatusMessage au lieu d'ignorer les résultats.

Un flux de travail qui s'était précédemment terminé avec succès lors de la fusion de Float clés distinctes échouera désormais avec une erreur de détection de collision telle que "statusMessage": "(collect_by_key_test.wdl Ln 17 Col 47) No such function: collect_by_key\n Map[Float, Array[String]] collected = collect_by_key(pairs_with_collision)"

Vous pouvez utiliser l'une des trois approches suivantes :

À venir (préavis de 60 jours à compter du 22 septembre 2026)

La division flottante (/) renverra des décimales et non des entiers tronqués.

Comportement actuel : l'/opérateur sur les Float opérandes renvoie l'entier le plus proche. Par exemple, 5.0 / 2 renvoie2.0, non2.5. Si les deux opérandes sont Int (par exemple,5 / 2), le résultat renvoie 2.

Changement à venir (30 novembre 2026) : La division flottante sur les opérandes flottants reviendra avec une précision de 16 décimales. Après cette date, 5.0 / 2.0 retournera2.5, 150.0 / 7.0 retournera 21.428... au lieu d'une valeur entière.

La précision du résultat dépend de la façon dont il est consommé : si le type de résultat estFloat, la valeur est calculée avec 16 chiffres décimaux de précision ; si le résultat est contraint à a, String il est formaté en 6 chiffres décimaux à la place.

Par exemple, 5.0 / 2.0 retournera2.5, et 150.0 / 7.0 retournera 21.4285714285714 sous forme deFloat, mais 21.428571 s'il est interpolé dans un. String

Int / Intles expressions telles que ne 5 / 2 sont pas affectées et continueront à renvoyer 2.

Pour garantir des résultats entiers quelle que soit la version du moteur, insérez la division flottante dans floor() ou ceil() :

Si votre flux de travail attend intentionnellement des résultats décimaux à partir de la division flottante, aucune modification n'est nécessaire. Le comportement de division à venir à partir du 30 novembre 2026 renverra également les décimales.

Remarque : 5/2 renverra toujours 2 lorsque l'/opérateur est appliqué aux entiers.