DPL-1081 [BUG] Don't allow selection of inappropriate templates

[KatyTaylor]

Describe the bug On the 'Select Plate Template' screen in the Cherrypicking pipelines, you are allowed to select templates that are not appropriate for the intended size of the destination plate. This can cause an unhandled exception to occur when the next screen is loaded.

RT Ticket Number Would prevent https://rt.sanger.ac.uk/Ticket/Display.html?id=796306 from happening again in future.

To Reproduce Steps to reproduce the behaviour:

1. Go to page 'UAT Actions' - Generate Plate (defaults are fine) - copy resulting barcode
2. Go to homepage - 'Create Submission'
3. Template = "Cherrypick for Fluidigm", Fluidigm Chip = "Fluidigm 192-24"
4. Add Order
5. Fill out a study and project
6. Add Samples - from Plate and Wells - paste barcode you copied earlier
7. Click off box, click Save Order, then Build Submission, refresh page until submission built
8. Go to Pipelines - Cherrypick for Fluidigm - select box associated with your submission, click Create Batch - Submit
9. Click Select Plate Template
10. Select Output plate purpose as "Fluidigm 192-24" (Problem - how to get to a screen where this is an option - still need to work out - think you might have to work through several cherrypicking steps to get there, because there are multiple request types in the submission)
11. Notice Template list includes many templates whose size is not 192 (in the database, these are Labware where sti_type is "PlateTemplate")

Expected behaviour The template list should only contain templates whose size matches that of the output plate purpose.

Also, if they do somehow manage to select an inappropriate template, the exception should be handled gracefully. More is explained below.

Additional context In the RT, the exception came from workflows > _plate.html.erb line 20 - undefined method[]' for nil:NilClass, meaning thatcurrent_wellwasnilon one of the iterations. current_wellis set bycurrent_well = plate[col*plate_rows + row]- this was trying to access an element that was not in the array. This happened becauseplatecontained 96 wells, whileplate_rowsandplate_cols` were 16 and 12 respectively - so the sizes were mismatching.

plate, plate_rows and plate_cols are passed in by _cherrypick_batches.html.erb and generated by _cherrypick_handler, at the end of render_cherrypick_task method. @plate_rows and @plate_cols come from the destination plate, if it's a partial, or else the destination plate purpose. @plates is generated by pick_new_plate in cherrypick_task - initially a list of wells by build_plate_wells_from_requests, then they get split into plates by the lambda push_completed_plate, after the check current_destination_plate.full?. current_destination_plate.full? comes from pick_target.rb, which uses the size passed in from the template (selected in the UI.

So ultimately, the plate purpose size and the plate template size were mismatched and it should be enforced that they are the same.

[SHIV5T3R]

It seems this issue arises when trying to cherrypick samples that belong to plates of different sizes. There will be two (or possibly more) options when selecting an output plate purpose. This causes there to be plate templates of varying sizes to choose from, which will cause an error when mixed.

There are a couple of options that we have to go about this if this isn't an intended/common use case:

1. Dynamically update the plate templates dropdown to reflect the size of the output plate purpose (ideal)
2. Display a warning when conflicting plate templates are chosen

If this does have a use case, then further discussion would be needed.

[KatyTaylor]

Thanks for the update. Just to add a bit more detail - it's when trying to cherrypick a batch where a) there are no 'next requests' i.e. this is the last request in the chain of requests in the submission, and b) the requests don't all have the same size of 'target purpose' (meaning the purpose of the intended destination plate) - this is selected while making the submission in the following screen:

We've contacted the customer who raised the RT ticket to try to understand the use cases more and decide on a solution.

[KatyTaylor]

Email from Joe D:

To the best of my recollection, I believe that the root cause was attributed to human error at the time. After scanning in the IFC assay chip barcode, Sequencescape automatically tabbed down into the next available data entry point - “Plate Template”. I subsequently scrolled to the bottom of the page to submit the sample batch. Unbeknown to me, I must have accidentally switched the template from "Fluidigm 192.24 Template" to “H12 Empty” instead of scrolling to the bottom of the page. We have since introduced a CAPA to double-check that the correct plate template is selected prior to batch creation. Generally speaking, we create our own sample submissions for our Fluidigm QC workflow, so I am somewhat reluctant to directly involve the SSR’s on this occasion. I would however be happy to discuss this issue in greater detail, how to improve the process and assist you in answering any further questions that you may have.

Write-up of chat with Joe & Ada from Sample Prep team 26/4/24:

Notes:

• When making a (Fluidigm cherrypicking) submission, there are 2 options to select: 192 & 96 (see screenshot in previous comment).
• When selecting rows in the Fluidigm Cherrypicking Pipeline inbox, to submit for a batch, it’s never intentional to mix the above options - should only be plates destined for a 192 chip, or plates destined for a 96 chip.
• They mentioned there is some validation happening here - it ‘knows’ when a 96 batch is intended and doesn’t allow them to select more than 96 samples, and the same for a 192 batch (Actually, ideally it would limit it to 95 and 190, as they leave some wells empty). The button is greyed out in this case.
• When selecting the rows from the inbox table, they are referring to paperwork (created after making submissions, I think) that shows them the plate barcodes they should be selecting.
• There could sometimes be multiple rows for one plate barcode - this is if the plate is split across multiple studies - you are forced to create separate submissions for different studies. They would always select these rows together and submit in the same batch. This is the place where there has been the most user error - missing one of the rows when selecting rows for a batch.
• The thing they would most like changed is the ability to roll back just one step in the pipeline, rather than having to go right back to the beginning - and without having to submit a ticket to PSD. They’ve had quite a few issues (due to the previous bullet point) - 6 times in 2 years - where they’ve had mistakes, and sometimes have to wait a couple of days before being able to proceed. ‘Steps’ in the pipeline here refer to sequential cherrypicking batches. The submission covers multiple request types (STA, STA2 etc.) - and each one is a cherrypick, where the output plate of one pick is the input of another.
• They mentioned that there’s a lot of tedious clicking - sometimes they have to click through the submission screen 20 times in a row. I suggested using the batch submission interface (spreadsheet-based) instead - but, it sounds like the way they do their submissions is integrated into their lab process, how they order their work etc, and it would need some thought as to how to improve this.

Thoughts:

• Why are they using SS cherrypicking rather than a Limber pipeline? If they don’t need all the flexibility of the cherrypicking screens, a Limber pipeline would involve less clicking.

Actions (for PSD):

• Test if the system allows you to select a mixture of ’96’ submissions and ‘192’ submissions in the inbox screen.
  • If it does allow this, look into how easy it would be to prevent that.
  • Don't spend too much more time on this as it's not high priority.
• (Not in scope of this Github issue) Chat with Neil about the tickets that have come in.
  • How easy would it be to allow roll back just one step?