Registro de cambios del motor WDL para HealthOmics

Esta página contiene el registro de cambios del motor WDL tanto para el modo estricto como para el modo WDL indulgente. En cada sección se resumen las nuevas funciones, mejoras y obsolescencias.

Nuevas características y mejoras

En la siguiente tabla se enumeran las nuevas funciones y mejoras del motor WDL en funcionamiento. HealthOmics

Fecha de cambio	Cambiar nombre	Descripción del cambio	Acción recomendada
22 de septiembre de 2026	Manejo uniforme de los extremos de línea del CRLF	HealthOmics recorta Windows-style (\r\n) los finales de línea de forma uniforme en todas partes y read_lines() read_tsv()read_map(), de forma que coincide con el comportamiento de las herramientas estándar de Linux.	Ninguna. No se requieren cambios en el flujo de trabajo.
22 de septiembre de 2026	zip()cross(), y read_tsv() ahora maneja correctamente las entradas de tipo mixto. Se pueden eliminar las soluciones alternativas de la fundición manual.	Las funciones incorporadaszip(), y read_tsv() ahora deducen correctamente cross() los tipos de sus valores devueltos. En versiones anteriores, estas funciones podían producir errores de tipo inesperados al combinar tipos mixtos (por ejemplo, Array[String] y Array[Int] en una zip() llamada), lo que requería la conversión manual de tipos en código WDL.	Si su flujo de trabajo incluye la adición de conversiones tipográficas explícitas para evitar errores tipográficos, o bien zip() cross()read_tsv(), puede eliminarlas. HealthOmics ahora deduce los tipos correctos automáticamente. Mantener las conversiones tipográficas existentes no provocará ningún error ni afectará al comportamiento del flujo de trabajo.
22 de septiembre de 2026	basename(path, "")fix devuelve el nombre del archivo en lugar de una cadena vacía.	basename(path, "")ahora devuelve el nombre del archivo. Por ejemplo, basename("/path/to/file.txt", "") devolverá "file.txt" en lugar de una cadena vacía.	Busca basename(x, "") llamadas en tus flujos de trabajo. Si existe alguna, comprueba que devolver el nombre del archivo es el comportamiento esperado.
22 de septiembre de 2026	Float-key detección de colisiones en collect_by_key()	collect_by_key()anteriormente trataban Float las claves como idénticas si coincidían con 6 decimales. Valores distintos, como «0.0000001y», 0.0000002 se fusionaron en un solo grupo. A partir de la fecha de cambio, HealthOmics detecta esta colisión en el momento de crear el flujo de trabajo y lo interrumpe con un error evidente en el campo GetWorkflow StatusMessage en lugar de descartar los resultados. Un flujo de trabajo que antes se completaba correctamente al fusionar distintas Float claves ahora fallará y se producirá un error de detección de colisiones como "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)"	Puede utilizar cualquiera de los tres métodos siguientes: Usa String las claves: cambia Array[Pair[Float, String]] Array[Pair[String, String]] y entrecomilla tus valores clave. Las teclas de cadena son siempre distintas y eliminan por completo el riesgo de colisión. Usa Int las teclas: cambia el tipo de clave para Array[Pair[Int, String]] multiplicar los valores flotantes por una potencia de 10 para conservar la precisión requerida como números enteros. Si Float las claves son inevitables, redondéalas primero con una precisión uniforme para asegurarte de que cada clave sea verdaderamente distinta y de que ningún dato se fusione de forma silenciosa. Normalice cada clave usándola round(value * 1000000.0) / 1000000.0 antes de pasarla a. collect_by_key()
Próximamente (con 60 días de antelación a partir del 22 de septiembre de 2026)	La división flotante (/) devolverá decimales, no enteros truncados.	Comportamiento actual: el / operador de los operandos devuelve el entero más Float cercano. Por ejemplo, 5.0 / 2 devuelve2.0, no2.5. Si ambos operandos son Int (por ejemplo,5 / 2), el resultado devuelve 2. Próximo cambio (30 de noviembre de 2026): la división flotante de los operandos flotantes se devolverá con una precisión de 16 decimales. Después de esta fecha, 5.0 / 2.0 devolverá2.5, 150.0 / 7.0 devolverá 21.428... en lugar de un valor entero. La precisión del resultado depende de cómo se consuma: si el tipo de resultado esFloat, el valor se calcula con una precisión de 16 dígitos decimales; si el resultado se convierte en un, String se formatea con 6 dígitos decimales. Por ejemplo, 5.0 / 2.0 se devolverá y se 150.0 / 7.0 devolverá 21.4285714285714 como a 2.5Float, pero 21.428571 si se interpola en un. String Int / Intexpresiones como estas no 5 / 2 se ven afectadas y seguirán devolviendo 2.	Para garantizar resultados enteros independientemente de la versión del motor, defina la división flotante en floor() oceil(): floor(5.0 / 2.0)→ siempre devuelve 2 ceil(5.0 / 2.0)→ siempre regresa 3 Si su flujo de trabajo espera intencionadamente resultados decimales de la división flotante, no es necesario realizar ningún cambio. El próximo comportamiento de las divisiones, que tendrá lugar el 30 de noviembre de 2026, también arrojará decimales. Nota: 5/2 seguirá devolviendo 2, ya que el / operador se aplica a los números enteros.