Add ability to resume execution of DQD checks#411
Add ability to resume execution of DQD checks#411ganisimov wants to merge 1 commit intoOHDSI:developfrom
Conversation
It happens that due to connection issues or other conditions executeDqChecks fails and progress is lost. When new resume argument is set to TRUE, file in outputFile path is used as source of check results instead of actual processing. Missing check results or results reporting error are re-processed. Note that outputFile must be set explicitely to make resuming to take effect. New results overwrite file in outputFile path. Addresses OHDSI#109
There was a problem hiding this comment.
This is a great addition, thanks. See my comment in-line.
Two general remarks:
- To be consistent with other OHDSI packages, I propose to either call this
incrementalmode like in CohortDiagnostics or add a new functionrunMissingCheckslike in Achilles. @katy-sadowski Maybe something to discuss in an upcoming WG meet? - Does this also work if a fatal error occurs? (e.g. connection lost, or R session timing out). I think the json results object only gets written at the end, so we might need to write out intermediate results to make this work for all cases where a DQD execution might be interrupted.
| conceptId = check["conceptId"], | ||
| unitConceptId = check["unitConceptId"] | ||
| ) | ||
| checkResultCandidates <- checkResultsSaved %>% dplyr::filter(checkId == currentCheckId & is.na(ERROR)) |
There was a problem hiding this comment.
This assumes the ERROR field is present in the results object, which is not the case when none of the checks resulted in an error.
|
I 100% want to add this feature, thanks @ganisimov for the contribution and @MaximMoinat for reviving the thread 😃 I've been thinking, however, that we might want to wait to add it in as part of the larger check-running workflow overhaul we've been discussing implementing in 2024. Part of the vision for that workflow includes moving away from the current "all-or-nothing" execution towards something more incremental that's aware of the relationships/dependencies between checks. I think that implementation will lend itself better to figuring out how/where to store incremental results, how to handle various failure modes, etc. Would definitely love to discuss this in a WG meeting early next year! |
3 participants
It happens that due to connection issues or other conditions executeDqChecks fails and progress is lost.
When new resume argument is set to TRUE, file in outputFile path is used as source of check results instead of actual processing. Missing check results or results reporting error are re-processed.
Note that outputFile must be set explicitely to make resuming to take effect. New results overwrite file in outputFile path.
Addresses #109