sequencescape
sequencescape copied to clipboard
sanger
DPL-341 [BUG] Cardinal - retrospectively failing a well should remove the samples from the downstream data
Describe the bug James thought of this while we were talking through this story (https://github.com/sanger/sequencescape/issues/3586)
If you fail a well in the Cardinal pipeline, it doesn't remove it from the downstream compound sample, and therefore the warehouse. Presumably it should? Putting this here so we don't forget about it.
To think about - if a sample is removed from a compound sample, that compound sample is now different - so the original one should probably be unchanged (since it may be used elsewhere), and a new one created?
Results from testing this in UAT
In each case, I failed one of the wells on the final plate (LCA Connect PCRXP), but at different points each time.
Failing before library prep is complete (before charge and pass): —> when created LCA Custom Pool using custom pooling file, it didn’t transfer the failed wells Then when tried to pool using pooling/new, got error “Source assets with barcode(s) 3981579827748 do not have any aliquots” So pooled without that tube Compound sample (in SS db) included 84 not 96 samples - excluded the failed ones
Retrospectively failing
Failing after charge & pass, before pooling into tube: —> Assume same outcome as above and below.
Failing after pooling into final tube, before requesting sequencing: —> Yes, they are removed from tube - therefore, expect same outcome as above.
Failing after requesting sequencing, before creating compound sample: —> Samples are removed from tube - so expect same outcome again.
Failing after creating compound sample: —> Samples are removed from the multiplexed tube, but not from the compound sample !! Presume this is incorrect behaviour !!
Discussed with James G whether this is inconsistent with existing behaviour in other pipelines. He found an email conversation with NPG - “Actioning [heron] sample deletion requests” 8/03/2021 - which discussed when and how updates to the LIMS propagate to the iseq_flowcell table in the MLWH. The summary is, I think, that:
- the intention of Sequencescape is that retrospective changes do propagate to the iseq_flowcell table.
- however, at the time of this email, there was a bug that meant that after retrospective well failure, the Batch was not automatically re-broadcast to the MLWH (and we don't think it's been fixed since)
- NPG (David J) expressed concerns about updates to the iseq_flowcell table after they had carried out their processing of it
From Stephen W today:
The inability to fail a sample in Limber post sequencing or after the next step in the process does not seem like an issue, as it is unlikely we would go back and do this.
Leaving this in the backlog, but won't prioritise for now.
Moved to the bottom of the list based on input provided by @KatyTaylor in https://docs.google.com/spreadsheets/d/14Rh3Q1l_d1tqcxZy6wploMXQV_kSiBfamkaJzwgjt8E/edit#gid=0
