refactor(api, robot-server): add error for multiple CSV definitions and less reliance on file reading/creating

[jbleon95]

Overview

This PR follows up both #15855 and #15907 with further refinements and small changes to defining and setting CSV parameters, along with behind the scenes refactors.

The two main user/client facing changes of this PR are changing the HTTP status code when invalid data file IDs are sent to the POST /runs, /protocols and /protocols/{protocolId}/analyses endpoints from 400 to 422, and raising a new IncompatibleParameterError when multiple CSV file parameters are added to a single protocol. The change in status code is to reflect that the error is not because of a malformed request, but because there was something in the request that could not be processed (in this case being the data file ID). The new error was added to align with the original PRD and the current UI. While there's no inherent technical limitation for multiple CSV parameters (other than the theoretical limitations with memory, number of file handlers, etc), there are unexpected UI bugs when multiple ones are defined and this change enforces only one per protocol.

The other major change of this PR is a non-user facing refactor of how we set the CSVParameter interface. Rather than passing the Path of the file to the interface and then using a TemporaryFile as the basis for all further access of the CSV file and it's contents, now the contents of the file (passed as bytes) is what everything else is based off of, including CSV parsing in parse_as_csv. With this change, we only ever make a temporary file handler when the user accesses .file. With this change reducing the chance of there being an open file handler, a new file_opened property was added to the public interface to reduce needless file opening. This is technically user-facing code meant more for internal usage, but I see no danger in exposing it, though if needed we can tag it is a private non-guaranteed method.

Test Plan and Hands on Testing

Tested the protocols in the previously mentioned PRs, along with ensuring the following one fails analysis.

metadata = {
    'protocolName': 'CSV Multiple Definitions Fails',
}

requirements = {
    "robotType": "Flex",
    "apiLevel": "2.20"
}


def add_parameters(parameters):
    parameters.add_str(
        display_name="Pipette Name",
        variable_name="pipette",
        choices=[
            {"display_name": "Single channel 50µL", "value": "flex_1channel_50"},
            {"display_name": "Single channel 1000µL", "value": "flex_1channel_1000"},
            {"display_name": "Eight Channel 50µL", "value": "flex_8channel_50"},
            {"display_name": "Eight Channel 1000µL", "value": "flex_8channel_1000"},
        ],
        default="flex_1channel_50",
        description="What pipette to use during the protocol.",
    )
    parameters.add_csv_file(
        display_name="CSV Data",
        variable_name="csv_data",
        description="CSV file containing labware and volume information."
    )
    parameters.add_csv_file(
        display_name="More CSV Data",
        variable_name="more_csv_data",
    )



def run(context):
    PIPETTE_NAME = context.params.pipette

    trash_bin = context.load_trash_bin('A3')
    tip_rack = context.load_labware('opentrons_flex_96_tiprack_50ul', 'D2')

    pipette = context.load_instrument(PIPETTE_NAME, mount="left", tip_racks=[tip_rack])
    csv_file_data = context.params.csv_data.parse_as_csv()

Changelog

• Raise IncompatibleParameterError when add_csv_file in the ParameterContext is used more than once
• Change status code of invalid data file IDs posted to runs and protocols endpoints from 400 to 422
• Refactor CSVParameter to only open temporary file handler when user requests one

Review requests

Should we label file_opened as private/use another way of preventing spurious temporary file creation just to close them?

Risk assessment

Low.

[sanni-t]

Looks great! It does make the code more straightforward and easier to follow (and of course, doesn't require carrying the original CSV file path anywhere)!

Have you looked into whether keeping the CSV file contents in memory affects the robot performance? The previous implementation also had to keep the contents in memory but only once they were accessed, while this one will carry the contents in memory since protocol loading. I think we are okay because of one file limit right now but worth checking at which point the csv file contents become too much to carry in memory.