4.3.1 -> 4.4.0

Overview

I currently am maintaining the software package opentronsfastapi (https://github.com/Koeng101/opentronsfastapi) which allows you to easily build fastapis that run on opentrons themselves. Basically, integrating opentrons with other hardware is way too clunky currently, so we’ve build software to present the opentrons as a REST server that you can pass parameters to (NOT passing python scripts).

The last update, 4.4.0, has caused our software to stop working, as the following exception is raised when run on real opentrons hardware:

INFO:     192.168.1.187:49982 - "POST /api/test_competent_cells?version_only=false HTTP/1.1" 500 Internal Server Error
ERROR:    Exception in ASGI application
Traceback (most recent call last):
  File "usr/lib/python3.7/site-packages/uvicorn/protocols/http/httptools_impl.py", line 385, in run_asgi
  File "usr/lib/python3.7/site-packages/uvicorn/middleware/proxy_headers.py", line 45, in __call__
  File "usr/lib/python3.7/site-packages/fastapi/applications.py", line 149, in __call__
  File "usr/lib/python3.7/site-packages/starlette/applications.py", line 102, in __call__
  File "usr/lib/python3.7/site-packages/starlette/middleware/errors.py", line 181, in __call__
  File "usr/lib/python3.7/site-packages/starlette/middleware/errors.py", line 159, in __call__
  File "usr/lib/python3.7/site-packages/starlette/exceptions.py", line 82, in __call__
  File "usr/lib/python3.7/site-packages/starlette/exceptions.py", line 71, in __call__
  File "usr/lib/python3.7/site-packages/starlette/routing.py", line 550, in __call__
  File "usr/lib/python3.7/site-packages/starlette/routing.py", line 227, in handle
  File "usr/lib/python3.7/site-packages/starlette/routing.py", line 41, in app
  File "usr/lib/python3.7/site-packages/fastapi/routing.py", line 197, in app
  File "usr/lib/python3.7/site-packages/fastapi/routing.py", line 148, in run_endpoint_function
  File "./opentronsfastapi/__init__.py", line 198, in inner
    ctx = opentrons_env.get_protocol_api(apiLevel)
  File "usr/lib/python3.7/site-packages/opentrons/execute.py", line 93, in get_protocol_api
  File "usr/lib/python3.7/site-packages/opentrons/hardware_control/thread_manager.py", line 130, in __init__
  File "usr/lib/python3.7/site-packages/opentrons/hardware_control/thread_manager.py", line 135, in managed_thread_ready_blocking
opentrons.hardware_control.thread_manager.ThreadManagerException: Failed to create Managed Object

The machine appears to get upset at this line - https://github.com/Koeng101/opentronsfastapi/blob/5cbed98c755123051887f38f1966a185664c8b2d/opentronsfastapi/__init__.py#L198 where I establish a new context to be used.

This new code was added by @ahiuchingau in 475ee25cd1aa3d85accae926c69cac30e920d112 on (https://github.com/Opentrons/opentrons/commit/475ee25cd1aa3d85accae926c69cac30e920d112#diff-daa3772563c5ebc4de4a12da9e046e1612d382a5b7adcf6d1b0eb8a841304b64 , great commit message btw).

For context in opentronsfastapi - we basically have a global lock mechanism for protocols that are currently running using an SQLite server (that also acts as an activity log). I know that opentrons has a local lock built into the software, but it isn’t very easy to hook that onto data to, say, tell a user which protocol is currently running, while maintaining a historical log of the activity.

Once the protocol gets a lock, it simulates the protocol (this works just fine). It then gets a protocol context, passes this into a thread that runs the protocol itself, and returns to the user a confirmation that the protocol has begun, along with a process ID and a version hash for the protocol’s function. The step of get_protocol_api is what is failing here.

Any ideas of how I can fix this? I’m not too familiar with the low-downs of how this is implemented or ways I could get around it. Thanks!

Steps to reproduce

You can run our example app on a real machine to raise this error.

Current behavior

Currently, I get the above error.

Expected behavior

I expect to be able to use this ctx in our software.