sanger / limber

A config-driven LIMS built on Sequencescape, primarily for running library preparation pipelines in the laboratory
MIT License
4 stars 8 forks source link

Y24-028 [BUG] Targeted NanoSeq - Fix metadata insert issue preventing creation of additional child plates from the LTN AL Lib plate #1628

Closed andrewsparkes closed 7 months ago

andrewsparkes commented 8 months ago

Describe the bug It is not currently possible to create any additional child LTN AL Lib Dil plates from an LTN AL Lib parent plate in the Targeted NanoSeq pipeline due to a limitation in the metadata creation code. It throws an exception when it detects a duplicate key on attempting insert. This prevents users from looping back to the LTN AL Lib plates and creating additional child plates (desired normal behaviour).

RT Ticket Number NA

To Reproduce Steps to reproduce the behaviour:

  1. Attempt to make more than one child plate from an LTN AL Lib plate in Limber
  2. Get errors regarding duplicate metadata
  3. In addition, child plate is made anyway, but binning is done incorrectly so needs to be cancelled

Expected behaviour Having discussion about this, see research story https://github.com/sanger/limber/issues/1623

Short term fix for this story: Allow request metadata to be overridden. See code in the create_request_metadata method in file app/models/labware_creators/pcr_cycles_binned_plate_for_t_nano_seq.rb which expects to insert fresh keys. We should check and overwrite the value if the key already exists. This is not ideal as it wipes out the record for previous runs if they loop without a new submission, but users are Ok with that for short term. Longer term better to have a new submission with different requests for follow up runs, on just the samples that they want to move forward, plus allowing partial transfers in the labware creator. See research story above. Possibly in the short term we could store history by re-writing each of the metadata to be overwritten with a prefix key e.g. date. Example 'original_plate_barcode' could become '20240321_original_plate_barcode'.

Screenshots NA

Additional context We currently make 9 metadata records for each well with a sample on the plate. This is already slow so adding additional queries to check whether each metadata key exists before creating or updating it will slow it further. Check it's not going to time out for a full plate.

Longer term we should only be uploading data for rows they want to take forward, and only recording metadata for those rows (a partial transfer to the child plate), but this is not the case at the moment and the code is writing metadata for all rows with samples.

SujitDey2022 commented 7 months ago

Team Discussion 26Mar2024:

  1. Do we want to have a history of previous metadata? May impact the current limited scope of work!
andrewsparkes commented 7 months ago

Also see integration suite PR here https://gitlab.internal.sanger.ac.uk/psd/integration-suite/-/merge_requests/123