chore(api): port absorbance reader commands to state update

[TamarZanzouri]

Overview

absorbance reader part of module state update.
https://opentrons.atlassian.net/browse/EXEC-756.
adding missing command unit tests for absorbance reader.

Test Plan and Hands on Testing

upload a protocol using the absorbance reader.
make sure all commands are working as expected.
make sure state is updated as expected.

Changelog

• added state update methods for absorbance reader state.
• added unit test files for absorbance reader commands.

Review requests

1. state update changes make sense? what do you think about having a class for all module state updates?
2. did I miss anything in the tests (I did not implement the commands)? do they make sense?

Risk assessment

low (if I did this properly). module state updates and missing tests.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.43%. Comparing base (906d841) to head (716ec08).
Report is 83 commits behind head on edge.

Additional details and impacted files

@@           Coverage Diff           @@
##             edge   #17113   +/-   ##
=======================================
  Coverage   92.43%   92.43%           
=======================================
  Files          77       77           
  Lines        1283     1283           
=======================================
  Hits         1186     1186           
  Misses         97       97           

Flag	Coverage Δ
g-code-testing	92.43% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[CaseyBatten]

Looks really good and the porting over to state update passes immediate sight checks for the same kind of behavior we had implemented already. Test coverage also looks good, don't see anything missing there. Thanks for doing this Tamar!

[CaseyBatten]

This logic looks solid down through it's usage. We utilize the files added data at the end of a run on the client as when looking through the run result to populate the list of files available for download via the app after the fact, so this should maintain that logic.

[SyntaxColoring]

Looks great, thank you!

Thank you for filling in the missing tests.

We're still missing tests for ModuleStateStore, but that was the case before, and it certainly doesn't need to get fixed in this PR. It does mean that we have to be careful about reviewing the _handle_absorbance_reader_commands() code by eye, though.

[SyntaxColoring]

Heads up that with the way these methods are written, you can only have one module update per command. If a command tries to do multiple, like this:

state_update.set_absorbance_reader_lid(...)
state_update.set_absorbance_reader_data(...)

Then the set_absorbance_reader_data() call will overwrite the set_absorbance_reader_lid() call.

I think that's fine for now, but I'm a little worried that someone in the future will try this and cause a confusing bug. Maybe if we threw in assert self.module_state_update == NO_CHANGE at the beginning of these methods to turn it into an error?

[SyntaxColoring]

Suggested change

	"""Tests for Magnetic Module commands."""
	"""Tests for absorbance reader commands."""

[SyntaxColoring]

Nitpick, but I wonder if there are nonintrusive ways we can simplify the control flow inside _handle_absorbance_reader_commands().

Like, to get rid of the repeated != update_types.NO_CHANGE checks, maybe we can do that check once at the beginning of the function and return early if it fails. Or have this function take a AbsorbanceReaderStateUpdate instead of a StateUpdate argument.

And maybe the module_id arg could be typed as an AbsorbanceReaderId instead of a str, so you don't have to do the AbsorbanceReaderId(module_id) casting in here.