Counting cases where `start` failed
islean opened this issue · comments
Description
When giving a status summary of the cases within an order, we do see miscounts happening for orders with cases failing the start command. This could be for several reasons:
- The flow cell is being requested from Hasta
- The flow cell is being re-demultiplexed
- The spring files need to be decompressed
- The spring files are currently being decompressed
- The Spring files are archived via DDN
- The Spring files are being retrieved via DDN
Should this be handled and if so how?
Suggested solution
Maybe add a blanket category failed start? Finding conditions without bugs for all these scenarios might be hard. Does it add much value?
This can be closed when
Either it has been decided that these cases are not worth it, or they are counted correctly.
Discussion
We would like to track all states of the data, but the number of statuses can be few:
Retrieving Data - any process where the data is queued, or in processing
Retrieval Failed - any status when the data flow is interrupted.
Discussion
We would like to track all states of the data, but the number of statuses can be few:
Retrieving Data- any process where the data is queued, or in processingRetrieval Failed- any status when the data flow is interrupted.
Do we have a clear way of finding Retrieval Failed? At a first glance this could be a huge number of different circumstances.
This issue applies only for rerun orders.
Possible reasons for Retrieval Failed:
No spring files in the housekeeper bundle or remotely.
- Flow cell cannot be found in StatusDB.
- Flow cell cannot be retrieved from PDC.
- Demultiplexing cannot start.
- Demultiplexing failed.
Or
Spring files stored remotely.
- Spring files can't be retrieved.
Then
No fastq files in housekeeper bundle, just spring files.
- Decompression failed.
- Storing failed.
Added to refinment 19-06-2024
Refinement
This feature is currently part of code that requires to be re-designed. Part of: #3452