DPL-nnn [BUG] Transfer::BetweenTubesBySubmission has race condition that leads to duplicate relationships

[JamesGlover]

Describe the bug When pooling multiple parent tubes into a single 'LB Lib Pool Norm' tube, the Limber LabwareCreators::FinalTube creates a transfer for each parent tube using the 'Transfer from tube to tube by submission' template. This template ends up using the Transfer::BetweenTubesBySubmission class in Sequencescape.

This transfer:

• Creates the transfer requests from the parent to the child
• Registers the parent tube as a parent of the child

This asset link is currently created asynchronously, which means we have a race condition.

In cases where we are pooling multiple tubes together, Limber will generate several transfers in quick succession. In cases where these parent tubes have a shared ancestor, it is possible that the labware graph (AssetLink which is maintained by acts_as_dag) will have duplicate relationships, which causes validation issues when attempting to progress further. This is because the asynchronous nature of the asset link generation, means that it is possible for both to be processed concurrently.

A quick fix would be to make asset link generation synchronous, rather than using the delayed job. This will have a slight impact on performance.

*** On longer term fixes Note: The target tube in this scenario is generate upfront when the submission is built. This is to allow SSRs to be able to adjust the sequencing on the tube prior to library creation actually being completed. As a result, there is no actual tube creation that takes place in LabwareCreators::FinalTube and instead the transfer looks up the appropriate labware. As a result, migrating the system to use something like transfer request collections, isn't entirely straight-forward. Two main blockers would be:

• Finding the tube upfront. (Or getting buy-in to drop upfront tube creation, along with actually removing it and handling the awkward switchover period)
• Adding the parent-child relationships (although if you did drop upfront creation this becomes fairly easy)

*** On Acts as Dag Acts as dag: https://rubygems.org/gems/acts-as-dag/versions/4.0.0 Although we actually are slightly ahead of the last release using the commit which is currently head of master: https://github.com/resgraph/acts-as-dag/commit/5e185dddff6563ee9ee92611555cd9d9a519d280

You might notice that this is ancient. I'll flag this as a liability in another ticket. (Maybe a better focus for my initial experiments with Neo4J than a fully robust aliquot graph)

RT Ticket Number Example in: #733662

To Reproduce Steps to reproduce the behaviour:

1. Go to page '...'
2. Click on button '...'
3. See error

Expected behaviour What was expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• Windows or Mac?
• Browser Chrome, Firefox, Safari or other?
• Browser version (use 'About' to look up)?

Additional context Add any other context about the problem here.