Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(api): Port touchTip, liquidProbe, and tryLiquidProbe location updates to StateUpdate #16261

Merged
merged 5 commits into from
Sep 18, 2024

Conversation

SyntaxColoring
Copy link
Contributor

Overview

More incremental work towards EXEC-652.

Test Plan and Hands on Testing

  • Run some protocols that do liquid probes and touch-tips. Make sure the path planning still looks right.

Changelog

This continues the pattern started in #16160. The following commands now use the new StateUpdate mechanism to update the pipette's logical state for the purposes of path planning:

  • touchTip
  • liquidProbe
  • tryLiquidProbe

Review requests

Double-check that the behavior of the code that I'm removing from PipetteStore is exactly preserved by the code I'm adding to TouchTipImplementation, LiquidProbeImplementation, and TryLiquidProbeImplementation.

Risk assessment

Medium.

* No need for two whole separate functions that only differ in the get_is_ready_to_aspirate() mock's return value, especially when the subject ignores that return value.
* Remove a redundant verify().
@SyntaxColoring SyntaxColoring requested review from TamarZanzouri and a team September 16, 2024 20:04
@SyntaxColoring SyntaxColoring requested a review from a team as a code owner September 16, 2024 20:05
well_location=params.wellLocation,
)
except PipetteLiquidNotFoundError as e:
return e, state_update, deck_point
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if its ok can we return a data model instead of a tuple? I find it confusing that the first arg can be an error/z pos

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm using a NamedTuple now, which is a little better, but I'm still cramming a float and Exception into a single attribute, which sounds like the real point of confusion.

I think I'd like to keep that as-is for type safety reasons. There will always either be a "no liquid found" condition with exception details, or there will be a z_pos, so I'd rather represent that in the type system than use asserts or whatever. I do see your point about it being confusing when two totally different things are in a single attribute.

Copy link
Contributor

@TamarZanzouri TamarZanzouri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great! a small nip we spoke about in person :-)

Copy link
Contributor

@TamarZanzouri TamarZanzouri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for taking the time to try and fix my nip! Lgtm!

@SyntaxColoring SyntaxColoring merged commit b17b17c into edge Sep 18, 2024
21 checks passed
@SyntaxColoring SyntaxColoring deleted the touch_tip_and_liquid_probe_state_updates branch September 18, 2024 13:44
SyntaxColoring added a commit that referenced this pull request Sep 18, 2024
## Overview

A trivial refactor as part of EXEC-652.

## Changelog

The `DefinedErrorData.private` attribute was obsoleted by PR #16160's
`StateUpdate` mechanism. PR #16261 deleted the last use of it, so we can
delete the attribute now.

`DefinedErrorData`'s sibling class, `SuccessData`, also has an identical
`private` attribute. We're not quite ready to delete that one, though.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants