fix(api): inherit protocol api errors from enumerated errors #15516
Conversation
|
A PR has been opened to address analyses snapshot changes. Please review the changes here: #15518 |
| class UnsupportedAPIError(Exception): | ||
| class UnsupportedAPIError(APIRemoved): |
There was a problem hiding this comment.
It looks like this exception is currently unused, so it doesn't really matter, but note that "API removed" is not the only thing that could be meant by "a protocol attempts to use an unsupported API." It could also mean that the protocol attempts to use an API that's too new, like if you tried to use "apiLevel": "2.19" on robot software v5.0. (We're currently just raising ValueError for that, but we probably shouldn't be.)
I wonder if we want just a generic code and exception for any protocol API version error. I'm not sure it's worth having 3 separate things for "too old," "too new," and "supported but invalid."
There was a problem hiding this comment.
Three is probably too many, yes. Two is probably good, breaking down into:
- Something is wrong with the combination of your code and API version.
- Your code used to be good but isn't anymore and furthermore that feature is never coming back ever ever so don't get your hopes up.
There was a problem hiding this comment.
But I think I'm trying to say that that specific breakdown of 2 is not sufficient to cover the case where your code is good, you just need to update your robot. That breakdown is covering problems like protocol_apilevel < MIN_SUPPORTED_VERSION and not feature_available_in(protocol_apilevel), but is not covering the problem of protocol_apilevel > MAX_SUPPORTED_VERSION.
|
A PR has been opened to address analyses snapshot changes. Please review the changes here: #15518 |
|
A PR has been opened to address analyses snapshot changes. Please review the changes here: #15518 |
| checked_detail["identifier"] = api_element | ||
| checked_detail["until_version"] = until_version | ||
| checked_detail["current_version"] = current_version | ||
| # make this cleaner?! |
There was a problem hiding this comment.
Remove or make a proper todo comment (I think the code is fine as is though)
| f"Deleting deck elements is not supported with apiLevel {self._api_version}." | ||
| f" Try increasing your apiLevel to {APIVersion(2, 15)}." | ||
| api_element="Deleting deck elements", | ||
| until_version="2.15", |
There was a problem hiding this comment.
Wait, was del protocol.deck[1] actually broken in 2.14? I don't think we ever documented that.
There was a problem hiding this comment.
Yeah, all we have is this:
Changed in version 2.14: Includes the Thermocycler in all of the slots it occupies.
Changed in version 2.15:
delsets the corresponding labware’s location toOFF_DECK.
We could update the versionchanged notice…or not.
<!-- Thanks for taking the time to open a pull request! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Use this section to describe your pull-request at a high level. If the PR addresses any open issues, please tag the issues here. --> This PR changes Protocol API APIVersionError to inherit from enumerated error IncorrectAPIVersion and Protocol API UnsupportedAPIError to inherit from enumerated error APIRemoved. # Test Plan <!-- Use this section to describe the steps that you took to test your Pull Request. If you did not perform any testing provide justification why. OT-3 Developers: You should default to testing on actual physical hardware. Once again, if you did not perform testing against hardware, justify why. Note: It can be helpful to write a test plan before doing development Example Test Plan (HTTP API Change) - Verified that new optional argument `dance-party` causes the robot to flash its lights, move the pipettes, then home. - Verified that when you omit the `dance-party` option the robot homes normally - Added protocol that uses `dance-party` argument to G-Code Testing Suite - Ran protocol that did not use `dance-party` argument and everything was successful - Added unit tests to validate that changes to pydantic model are correct --> # Changelog <!-- List out the changes to the code in this PR. Please try your best to categorize your changes and describe what has changed and why. Example changelog: - Fixed app crash when trying to calibrate an illegal pipette - Added state to API to track pipette usage - Updated API docs to mention only two pipettes are supported IMPORTANT: MAKE SURE ANY BREAKING CHANGES ARE PROPERLY COMMUNICATED --> # Review requests <!-- Describe any requests for your reviewers here. --> # Risk assessment <!-- Carefully go over your pull request and look at the other parts of the codebase it may affect. Look for the possibility, even if you think it's small, that your change may affect some other part of the system - for instance, changing return tip behavior in protocol may also change the behavior of labware calibration. Identify the other parts of the system your codebase may affect, so that in addition to your own review and testing, other people who may not have the system internalized as much as you can focus their attention and testing there. -->
Overview
This PR changes Protocol API APIVersionError to inherit from enumerated error IncorrectAPIVersion and Protocol API UnsupportedAPIError to inherit from enumerated error APIRemoved.
Test Plan
Changelog
Review requests
Risk assessment