BatchtoolsParam fails to propagate errors in bpiterate
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
Línea de trabajo
Start by reproducing the reprex at bpiterate with BatchtoolsParam, then compare its error handling with SerialParam, MulticoreParam, and SnowParam. Done means the failing callback propagates as an error rather than returning NULL results with an errors attribute, and bpok reports the failure consistently.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I've discovered a case where BatchtoolsParam behaves differently from other backends. Consider the following reprex:
library(BiocParallel)
library(iterators)
library(assertthat)
library(testthat)
## Convert a foreach iterator into a BiocParallel iterator
makeIter <- function(it) {
f <- function() {
tryCatch(it$nextElem(), error = function(e) {
if (e$message == "StopIteration") {
NULL
} else {
stop(e)
}
})
}
f
}
## Example non-error usage of makeIter
bpiterate(
makeIter(icount(10)),
sqrt,
BPPARAM = SerialParam()
)
#> [[1]]
#> [1] 1
#>
#> [[2]]
#> [1] 1.414214
#>
#> [[3]]
#> [1] 1.732051
#>
#> [[4]]
#> [1] 2
#>
#> [[5]]
#> [1] 2.236068
#>
#> [[6]]
#> [1] 2.44949
#>
#> [[7]]
#> [1] 2.645751
#>
#> [[8]]
#> [1] 2.828427
#>
#> [[9]]
#> [1] 3
#>
#> [[10]]
#> [1] 3.162278
## Correctly throws the error
expect_error(bpiterate(
makeIter(iterators::icount(10)),
function(x) stop("This function always throws an error"),
BPPARAM = SerialParam()
))
## Correctly throws the error
expect_error(bpiterate(
makeIter(iterators::icount(10)),
function(x) stop("This function always throws an error"),
BPPARAM = MulticoreParam(workers = 2)
))
## Correctly throws the error
expect_error(bpiterate(
makeIter(iterators::icount(10)),
function(x) stop("This function always throws an error"),
BPPARAM = SnowParam(workers = 2)
))
## Does not throw the error, but collects in attr(,"errors")
resList <- bpiterate(
makeIter(iterators::icount(10)),
function(x) stop("This function always throws an error"),
BPPARAM = BatchtoolsParam(cluster = "socket", workers = 2)
)
#> Submitting 10 jobs in 2 chunks using cluster functions 'Socket' ...
print(resList)
#> [[1]]
#> NULL
#>
#> [[2]]
#> NULL
#>
#> [[3]]
#> NULL
#>
#> [[4]]
#> NULL
#>
#> [[5]]
#> NULL
#>
#> [[6]]
#> NULL
#>
#> [[7]]
#> NULL
#>
#> [[8]]
#> NULL
#>
#> [[9]]
#> NULL
#>
#> [[10]]
#> NULL
#>
#> attr(,"errors")
#> attr(,"errors")$`10`
#> <unevaluated_error: not evaluated due to previous error>
#>
#> attr(,"errors")$`1`
#> <remote_error in FUN(...): This function always throws an error>
#> traceback() available as 'attr(x, "traceback")'
#>
#> attr(,"errors")$`2`
#> <unevaluated_error: not evaluated due to previous error>
#>
#> attr(,"errors")$`3`
#> <unevaluated_error: not evaluated due to previous error>
#>
#> attr(,"errors")$`4`
#> <unevaluated_error: not evaluated due to previous error>
#>
#> attr(,"errors")$`5`
#> <remote_error in FUN(...): This function always throws an error>
#> traceback() available as 'attr(x, "traceback")'
#>
#> attr(,"errors")$`6`
#> <unevaluated_error: not evaluated due to previous error>
#>
#> attr(,"errors")$`7`
#> <unevaluated_error: not evaluated due to previous error>
#>
#> attr(,"errors")$`8`
#> <unevaluated_error: not evaluated due to previous error>
#>
#> attr(,"errors")$`9`
#> <unevaluated_error: not evaluated due to previous error>
## This assertion fails
assert_that(!any(bpok(resList)))
#> Error: !any(bpok(resList)) is not TRUE
## This assertion passes
assert_that(!any(bpok(attr(resList, "errors"))))
#> [1] TRUE
Created on 2023-07-07 with reprex v2.0.2
With any other backend (SerialParam, MulticoreParam, SnowParam), the bpiterate call throws an error (verified here by calling expect_error). However, BatchtoolsParam does not throw an error and instead returns a list with all NULL elements and an attribute "errors" containing the errors thrown during iteration. Furthermore, bpok says this object is totally fine. I would expect BatchtoolsParam to behave the same as the other backends here.
- Lenguaje dominante
- R
- Estrellas
- 69
- Forks
- 32
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de Bioconductor/BiocParallel
-
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
Bioconductor/BiocParallel#286 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 50/100
Bioconductor/BiocParallel#285 ·
-
futile.logger may be archived from CRANQuizá libre de nuevo @Jiefei-Wang la tomó hace 268 días y no hay ningún pull request abierto. Abierto
Bioconductor/BiocParallel#284 · 2 comentarios · 1 asignado ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
Bioconductor/BiocParallel#283 · 2 comentarios ·
-
DoparParam: Captured stdout is relayed to stdout for some foreach adapters and stderr for othersAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Bioconductor/BiocParallel#277 ·
Todos los issues de Bioconductor/BiocParallel
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
ImperialCollegeLondon/ve_data_science#666 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
Los mantenedores suelen responder en 13 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100