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

[VickyTwig]

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

[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.

[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: ***@***.***>