bug: visualisation, run steps and labware position check refer to old protocol after update to 7.0.1

[VickyTwig]

[Edit by @SyntaxColoring: this is tracked internally as RESC-162.]

Overview

We updated the Opentrons app and the robot servers to 7.0.1 on 26/10/23.

Our current workflow is:

• create a new protocol using a config generator and a standardised Python protocol which reads the config file
• upload the config and the standardised protocol to the robot via the HTTP API
• for a subset of our protocols, run a labware position check via the Opentrons app

The problem after the update: The run steps, labware visualisation and position check refer to an old version of the protocol. However, when the protocol is run, it runs the new version.

What we've tried:

• Deleting the old protocol
• Turning the app and the robots on and off again

[NB: we appreciate this probably isn't a common workflow - it is temporary whilst we create a version of the labware position check in our own interface.]

Steps to reproduce

• Upload a protocol
• Update the app and robots to 7.0.1
• Upload a new version of the protocol with the same name to the robot via the HTTP API
• Run a labware position check via the Opentrons app
• Run the protocol via the Opentrons app

Current behavior

The run steps, labware visualisation and position check refer to an old version of the protocol. However, when the protocol is run, it runs the new version.

Expected behavior

The run steps, labware visualisation and position check refer to the latest version of the protocol and match the protocol that is run.

Operating system

Windows

System and robot setup or anything else?

Versions:

• Opentrons app and robot server versions: 7.0.1
• All our protocols are at least 2.0 (mostly 2.13+)
• The HTTP API: 3
• Python package: 6.2.1
• The app is run from Windows and Mac computers
• The HTTP request is sent from Mac computers when testing locally and then from a Fargate instance (Linux) when in production

Accessing the robot via wifi, sending an HTTP request to post the protocol and scp-ing a configuration file to the robot. Then running the labware check through the Opentrons app.

Not sure whether this issue is related: #13839

[SyntaxColoring]

👋 Hey, thanks for the detailed report.

The run steps, labware visualisation and position check refer to an old version of the protocol.

Does it seem like it could be referring to the latest .py file, but an old config file?

We have a couple things that might be interacting here in a confusing way.

First: The robot analyzes a protocol only when you first upload it via POST /protocols. If, after that, you scp over some stuff that affects the protocol's behavior, those changes in behavior won't be reflected in the protocol's analysis. The analysis will be stale.

Second: When you upload a protocol via POST /protocols, the robot no-ops if it's a protocol it's already storing, as an optimization. The comparison is made by comparing the files in the POST requests. This means if you repeatedly upload the exact same Python file, the robot will only analyze it the first time. It mistakenly skips re-analysis because it doesn't know about any externally-scp'd files that have changed its behavior since it was first uploaded.

So my theory at the moment is that you're running into some combination of those.

You want to guarantee that you're looking at a fresh analysis, representing, as closely as possible, what a new run would actually do. I think these are your options today:

• The easiest is probably to make the file different every time you upload it, so it always looks like a new protocol that needs to be analyzed. Appending a timestamp to the filename should be sufficient for this, like my_protocol_1698624000.py.
• Alternatively, you could fully delete and recreate the protocol every time you upload it. Delete the protocol with an HTTP DELETE /protocols/{id}. You may need to also delete the runs that were created from that protocol, with HTTP DELETE /runs/{id}.

Also, if your protocol has dependencies that it's expecting to be externally scp'd, make sure you scp them before doing POST /protocols. Otherwise, the protocol analysis will start without waiting for those dependencies to be present on the system.

Let me know if that helps!

[VickyTwig]

Thanks Matt - that all sounds really helpful advice. I'll give it a go and give you an update! Best, Vicky

…

On Mon, 30 Oct 2023 at 20:48, Max Marrone ***@***.***> wrote: 👋 Hey, thanks for the detailed report. The run steps, labware visualisation and position check refer to an old version of the protocol. Does it seem like it could be referring to the latest *.py* file, but an old *config file*? We have a couple things that might be interacting here in a confusing way. First: The robot analyzes a protocol only when you first upload it via POST /protocols. If, after that, you scp over some stuff that affects the protocol's behavior, those changes in behavior won't be reflected in the protocol's analysis. The analysis will be stale. Second: When you upload a protocol via POST /protocols, the robot no-ops if it's a protocol it's already storing, as an optimization. The comparison is made by comparing the files in the POST requests. This means if you repeatedly upload the exact same Python file, the robot will only analyze it the first time. It mistakenly skips re-analysis because it doesn't know about any externally-scp'd files that have changed its behavior since it was first uploaded. So my theory at the moment is that you're running into some combination of those. You want to guarantee that you're looking at a fresh analysis, representing, as closely as possible, what a new run would actually do. I think these are your options today: - The easiest is probably to make the file different every time you upload it, so it always looks like a new protocol that needs to be analyzed. Appending a timestamp to the filename should be sufficient for this, like my_protocol_1698624000.py. - Alternatively, you could fully delete and recreate the protocol every time you upload it. Delete the protocol with an HTTP DELETE /protocols/{id}. You may need to also delete the runs that were created from that protocol, with HTTP DELETE /runs/{id}. Also, if your protocol has dependencies that it's expecting to be externally scp'd, make sure you scp them *before* doing POST /protocols. Otherwise, the protocol analysis will start without waiting for those dependencies to be present on the system. Let me know if that helps! — Reply to this email directly, view it on GitHub <#13868 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6ALP2TAICZASYJRL45DU33YCAHAFAVCNFSM6AAAAAA6V3QPUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBWGAYTGMJYGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[VickyTwig]

We've renamed the file each time we upload it and this seems to have solved the issue. Will close. Thanks for your detailed suggestions!

[SyntaxColoring]

We're tracking this as #14598, moving forward.