bug(app): cannot upload bundled protocol into app version 5.02

[mgalardini]

Overview

I'm trying to use a bundled protocol with the newest version of the app. The exact same bundle works with an earlier version (4.7.0), but with the new version a generic error is thrown.

Steps to reproduce

• enable developer "mode" and the ability to upload bundled protocols, the restart
• go to protocols and select the attached bundled protocol

Current behavior

The app displays the following message: "field required", and the javascript console indicates "Invalid Request" for pointer /protocolFile. The error is somewhat similar to issue #9538, although the pointer is different, and so I don't think this is a duplicate issue.

Here's a screenshot:

Expected behavior

As with app version 4.7 we expect the bundled protocol to be loaded correctly and be able to run it. For now we are simply running the old version but eventually we would like to move to the new version.

Thanks for your help

[mcous]

@mgalardini thanks for your feedback! We intentionally removed the bundled protocol uploads in the 5.0 release. As a rule, anything hidden behind the "Developer Internal" settings are not intended to be used by end-users, and are subject to change and removal without warning.

One reason that we removed this experimental feature is that the 4.x software relied on a very bespoke communication channel to send protocol files to the OT-2. In the >=5.x software, we replaced this channel with an HTTP API. We fully intend to expand the app and this new API to officially support multi-file protocols. A few issues you can keep an eye on for that effort:

• protocol-engine: allow using data files with a protocol  #8072
• protocol-engine: allow using python support files with a python protocol #8073

So that I might better surface this feedback to our product and design teams, what are you currently using bundled ZIP protocols for?

[mgalardini]

Thanks for your reply; I understood this functionality was sort of a workaround (i.e. there is no mention of it in the API docs), but for our current workflow it was just perfect. I am writing the python protocol and another member of the lab is preparing a simple csv file with sample positions and target concentration for a compound. The protocol reads this file and computes on the fly the required pipetting volumes, then my colleague can use the app interface to run the protocol, which is nice for them as it allows pre-calibration and pause/resume/abort controls.

While we can continue with the old version for the time being, is there any way to have the same functionality with the latest stable version of the app? One workaround I thought of is to generate a different python protocol file for each csv file we have, with the precomputed volumes in a data structure (e.g. a dictionary). That is however less generalizable than having the data and the code as separate entities.

[mgalardini]

Sorry for getting back at this issue, but I though of asking a follow-up question: is there a way to obtain a json file from a custom opentrons script? If so that would be an acceptable solution for us: we run the script with no connection to the robot, so that the data can be accessed in its own file, and then upload the resulting json to the app. This way the workflow is identical to running protocols made with the protocol builder. Would you know if that is possible? I could not find mentions of it in the API docs.

[arogozhnikov]

@mcous this issue was opened a year ago, and the issues you linked - around two years ago.

Is there any way to upload bundles? I serialize protocol inputs with pydantic and would like to use it.
Also, the script turned out to be ~1000 lines and if there is a way to split into files, I'd like to use it.

[mcous]

@arogozhnikov I left Opentrons earlier this year, so I will not be able to help further with this issue. Sorry!

For more complex protocol uploads than the app allows, you should explore the HTTP API. As of 6.2.x, the HTTP API will allow you to upload a main protocol file along with 0 or more supporting labware definitions. The upcoming 6.3.0 release (which looks to be making its way through testing now, from what I can see), will add data files, like csv and txt to the allowed support file types, so #8072 will be closed by that release.

I believe there's quite a bit of work that still has to happen before protocols with multiple Python files could work. Previous experimental versions of this feature (which does not include "bundled protocols") relied on hacks, so I'd guess #8073 is going to stay open for a while.