sequencescape
sequencescape copied to clipboard
GPL-907 UKB offshoot data issue - 5 failed samples
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
- They started off on stock plate DN590302W
- They were picked onto 'PF Cherrypicked' plate DN604425J
- They were also picked onto 'PF Cherrypicked' plate DN604426K (by mistake, because of a plate swap)
- If you take plate DN604426K and follow the transfers down the pipeline, you see the samples on 'PF Post Shear' plate DN605291R, but you don't see them in the relevant well in 'PF-384 Post Shear XP' plate DN606123G - instead, you see an empty well
- The samples have 'passed' transfer requests into the wells on the 384 plate, but the target well has no aliquots
- When you fail a well, it does delete the aliquots from downstream wells, however the transfer request should be marked as failed.
Who the primary contacts are for this work Rich C, Katy
Additional context or information
- Rich C noticed this while checking the data fix for RT #683460
- He has a spreadsheet that lists wells that failed library prep
- This list contains the following samples: UKBB_MP8190992 UKBB_MP8191000 UKBB_MP8191009 UKBB_MP8191016 UKBB_MP8191018
- However, these are not the actual samples that were affected, because the LIMS data was wrong due to a plate swap (see RT #683460)
- Once you 'translate' these into the correct samples, you get the ones I've listed at the top of the issue
- The empty wells situation was there before I ran the data fix for this RT - the only thing that changed was the names of the samples that were affected.
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).