Closed KatyTaylor closed 1 month ago
This is no longer needed:
It looks like Sequencescape has behaved as expected here - the data is correct.
If you look at the plate summary view - http://sequencescape.psd.sanger.ac.uk/plate_summaries/DN604426K - you can see the failure here - the samples were retrospectively failed by Adam L on 2020-01-08 11:42:35 +0000 on the DN605291R - PF Post Shear plate. If you scan this into limber you’ll see the failed wells (the transfer requests into these wells have state failed). The wells are empty from the next plate onwards, because this is the effect it has when you retrospectively fail wells – it removes them from downstream wells.
While confirming this with Jamie we found there might be a possible fail wells bug that prevented them from failing the wells on the correct plate. They wanted to fail them on the PF Lib Q-XP2 plate, but can't due to a bug that James is solving as part of https://github.com/sanger/limber/issues/648 Instead of failing the wells on the parent 384 well plate, they tend to go back to the last 96 well plate to make sure that the correct well is failed (because it's easy to get it wrong when mapping fro 96 to 384).
Description
The following samples failed library prep, but they do not show as failed, they instead are shown as 'empty wells' from a certain plate onwards in the pipeline.
UKBB_MP8190896 UKBB_MP8190904 UKBB_MP8190913 UKBB_MP8190920 UKBB_MP8190922
Who the primary contacts are for this work Rich C, Katy
Additional context or information