BatchtoolsParam fails to propagate errors in bpiterate
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- R
- Sterne
- 69
- Forks
- 32
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus Bioconductor/BiocParallel
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 65/100
Bioconductor/BiocParallel#286 · 1 Kommentar ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 50/100
Bioconductor/BiocParallel#285 ·
-
futile.logger may be archived from CRANEvtl. wieder frei @Jiefei-Wang hat das vor 270 Tagen übernommen, und es ist kein Pull Request offen. Offen
Bioconductor/BiocParallel#284 · 2 Kommentare · 1 zugewiesene Person ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
Bioconductor/BiocParallel#283 · 2 Kommentare ·
-
DoparParam: Captured stdout is relayed to stdout for some foreach adapters and stderr for othersOffen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
Bioconductor/BiocParallel#277 ·
Alle Issues in Bioconductor/BiocParallel
Ähnliche Issues
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 92/100
Open-Systems-Pharmacology/OSPSuite.ParameterIdentification#315 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
hubverse-org/hubUtils#307 ·
-
ai-authored model:claude-opus-5-5
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
bug ready
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
montilab/SigRepo_Server#144 ·
Maintainer antworten meist innerhalb von 1 Tag