add error handling to fastq clean #4206
Conversation
| @@ -86,20 +86,24 @@ def clean_fastq(context: CGConfig, case_id: str | None, days_back: int, dry_run: | |||
|
|
|||
| cases: list[Case] = get_cases_to_process(case_id=case_id, days_back=days_back, store=store) | |||
| if not cases: | |||
| LOG.info("Did not find any FASTQ files to clean. Closing") | |||
| return | |||
|
|
|||
| cleaned_inds = 0 | |||
| for case in cases: | |||
| sample_ids: Iterable[str] = store.get_sample_ids_by_case_id(case_id=case.internal_id) | |||
| for sample_id in sample_ids: | |||
There was a problem hiding this comment.
Completely unrelated to anything in this PR but is this logic not off? Should we not look for old samples rather than old cases? What happens if we have a re-run so the sample is in multiple cases?
There was a problem hiding this comment.
Maybe it would be a good idea to open a new issue to reproduce this situation: a sample belonging to two cases, one more than 60 days old and one ongoing to evaluate the consequences of this
There was a problem hiding this comment.
There are more issues around the case-centric handling of sample properties. I agree with you Isak that, since a sample can be in multiple cases it could potentially receive multiple "compression, cleaning" and so on states based on the current case that is evaluated.
|
Description
Closes #3817
Adds error handling to the CLI command
cg compress clean fastqso that any exception raised when cleaning a single sample is caught and logged without affecting the cleaning of other samples.Added
How to prepare for test
uspaxaHow to test
cg compress clean fastq --case-id <some-case>Expected test outcome
Review
Thanks for filling in who performed the code review and the test!
This version is a
Implementation Plan