GPL-753 Create Labwhere records for source plates on Beckman

[andrewsparkes]

Control plate tracking split out into: #202

User story
As Sample management and R&D we would like to automatically create Labwhere records for source and control plates that will be destroyed following Beckman Cherrypicking on a robot.
Specially this is for the following scenarios:
Control plate is used in a run (these plates are single use and have unique barcodes) - these go to the bin after the run
Source plates that are not readable / missing their barcodes - these go into the output stacks and to the bin
Source plates that contain only negatives - these go into the output stacks and to the bin
Source plates that have been fully picked - these go into the output stacks and to the bin

We do not want Labwhere events written for these scenarios:
Source plate has no plate map data - these go back to the input stack and are manually recorded in labwhere
Source plate is only partially picked - these go back to the input stack and are either used in the next run or manually recorded in labwhere if they are stored overnight
Destination plates - these will be manually recorded in Labwhere

Who are the primary contacts for this story
Scott T
Danni W

Acceptance criteria
To be considered successful the solution must allow:

• Labwhere records are created for plates as for the scenarios above.

Dependencies
https://github.com/sanger/General-Backlog-Items/issues/76
#176

Additional context
Consider adding a Labwhere endpoint to lighthouse that the Beckman method can call with a and either a
or a more human readable abstract location type that is translated in the lighthouse configs.
Or
Can we call Labwhere directly from the Beckman method? does labwhere have a direct API endpoint we can use? what information is required?

[JamesGlover]

Event documentation: https://ssg-confluence.internal.sanger.ac.uk/display/PSDPUB/Cherrypicking+Events

[JamesGlover]

So working on adding event callbacks to handle this. Should only need one or two, depending on message structure.

[JamesGlover]

Questions:

1. What is the value in updating the labwhere location of unrecognised plates? We'll only be able to say 'something' went in the bin.
2. What event is associated with used control plates? lh_beckman_cp_source_completed?

[JamesGlover]

Scott T Standup 27th Nov:

1. No real value in recording locations of unknown entities, given we are still tracking the failed scan event.

[JamesGlover]

Labwhere scan events usually track the user responsible, but currently the API requires that gets specified as ‘user_code’
The lighthouse is getting the user login, but as mentioned in the stand-up yesterday we don’t have the swipecard, at least not in Sequencescape. So, I see a few options:

1. Update the labwhere API to also allow users to be specified by login. Then just pass through the login that got passed to the plate event. This will fail if:
   a) The user types their login incorrectly.
   b) The user isn’t registered in labwhere.
   This will result in no labwhere scan being recorded.
   There is also a risk that the person clearing the output stack is not the same person who started the robot, so the scan will be mis-ascribed.

2. Instead of sending a used identifier to labwhere, send an identifier of the robot instead. Register each robot in labwhere. This has the advantage that its easy to distinguish the automated scan events from manual ones, and is substantially easier to implement. It does make it more work to discover who was the robot operator from within labwhere, but that information will still be logged in the event warehouse.

3. We DO take the user swipecodes upfront, and build a plain text lookup for the user-ids/beckman validation. Perhaps we could source this from labwhere as it doesn’t look like that’s hashing them.

I’m inclined to suggest 2 at the moment, primarily because:
It’s simpler
We’re less likely to end up with a situation where we can’t update labwhere
We’re not actually throwing away any information, as users are still tracked in the events warehouse.

[JamesGlover]

Control plate is used in a run (these plates are single use and have unique barcodes) - these go to the bin after the run

Currently we don't have any calls from Beckman to trigger this action. Personally I'd favour:

Original suggested action, replace by alternative in comment below

• Add new lh_beckman_cp_control_completed event created on control plate usage
• Control plate should have role cherrypicking_source_labware
• Should still include robot as subject
• Add new handler to extract the barcodes for these plates (Will be almost identical to existing handler, just extracting a different role)

We could reuse the existing lh_beckman_cp_source_completed event type and subject types, and wouldn't need a new callback, but that feels questionable as it will make it difficult to filter out controls.

It is possible to extract control plates from the lh_beckman_cp_destination_created messages, but this would require extracting the barcode from the control sample names, which feels a bit brittle. In addition, it would miss control barcodes which were used, but the destination plate never completed. There would also be a delay updating control plate locations if the destination plate completion was delayed.

Another alternative would be for beckman to talk to labwhere directly, but I don't see much value in this.

[JamesGlover]

After a bit of chat:

1. Scott T confirms that while there is intent to migrate to unique barcodes generated by Mixtio, this is not in place yet. So the controls component of this is blocked until that is in place.
2. Control samples are included in the lh_beckman_cp_destination_created and will be in the lh_beckman_cp_destination_failed event
3. However these events are generated in SS, co can't hook into the callback system
4. Also, adding the control plates to these events would necessitate generating a uuid, and possibly persisting it if we have two such events.
5. It is unlikely there will be time available for adding calls to our APIs from the robot scripts in the near future

Thus easiest solution is to probably update the control plate locations as part of the lh_beckman_cp_destination_created/lh_beckman_cp_destination_failed actions, once the necessary changes have been made to control plate generation. We won't have events available at this stage, so can just call the labwhere module directly. (Or do the update in Seqeuncescape, but then we'd be needing to keep track of heron bin barcodes in SS, or pass them across the API, which just feels unnecessary. )