DPL-nnn [BUG] Stock resource deadletters

[emrojo]

Describe the bug When processing a stock_resource message with UWH consumers:

{"stock_resource":{"stock_resource_uuid":

getting the following error:

Dead-letter Exception: Contains two elements with the same composite identifier: combination of id_stock_resource_lims, id_sample_tmp should be unique.

RT Ticket Number If applicable

To Reproduce Steps to reproduce the behaviour:

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

Expected behaviour ~To consume the message without problem~ [JG] I'm not sure that is the solution. The message content is invalid, so we should reject it. We need to fix up the cause (See comments)

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.

[JamesGlover]

To you have a full payload that was causing the issue?

The validation error sounds like a sensible one so it would be good to know if:

1. Its triggering in error (ie. we don't have a duplications)
2. We are generating invalid messages with duplicate samples
3. The constraint is overlooking a valid use case for duplicate samples in the same stock resource so we need to relax the constraint and add something else to the composite id (and possibly another column to the database)

[JamesGlover]

From an example I found Receptacle.find(61764326) it looks like chromium libraries, in a 'LB Lib PCR-XP' plate. This is not a stock resource, so we shouldn't be generating a stock resource message.

Looking closer these samples came in from a plate-library-manifest, where I can kind of understand why we're triggering the broadcast. Not sure how we also managed to trigger it for the Lib PCR-XP plate though.

[JamesGlover]

Ahh, so the 'LB Lib PCR-XP' was originally picked as a stock plate, and was then converted.

So we had a non-stock resource placed in a stock plate, and generated the stock-message. (The initial manifest entry behaved correctly and didn't generate a stock resource)

Still trying to track down where we register new-picks as stocks. (Or what other route through the system would have lead to this behaviour)

[JamesGlover]

Ahh, starts here: https://github.com/sanger/sequencescape/blob/e768cecd5f6b03254a68fdb76e662a3758765419/app/models/cherrypick_pipeline.rb#L35 And ultimately handled here: https://github.com/sanger/sequencescape/blob/01815b18752803118beaf7a8a833764967f380e3/app/models/messenger_creator.rb#L3

Little tricky, as the code also handles broadcast of fluidigm plates. Could be a case of letting the Messenger's validate themselves, although would been to be careful that in this case we simply failed to save the new messenger, rather than raise an exception or block progress.