bug: Manual update button is sometimes grayed out even when the robot is available to accept an update

[SyntaxColoring]

Overview

The Opentrons App has a Browse button to manually send an ot2-system.zip system update file to the OT-2. For robustness, this is supposed to work even when the robot server on the robot has crashed. Only the update server needs to be working.

However, even when the update server is working and you should be able to do this, the Opentrons App sometimes grays out the Browse button and makes it unusable.

Steps to reproduce

[Edit: This is questionable. See comment below.]

1. Connect to an OT-2 with the Opentrons App. You don't actually need to click the blue toggle button; the robot just needs to be showing up in the left sidebar with the toggle button available and without any orange error banner.
2. Observe that the manual update Browse button is clickable.
3. ssh into the robot and run systemctl stop opentrons-robot-server.
4. Wait for an orange error banner to appear in the Opentrons App.
5. Observe that the Browse button is now grayed out and unclickable.
6. Close and reopen the Opentrons App.
7. The orange error banner will still be there. However, observe that the Browse button is available again.

Current behavior

It seems like the Opentrons App will incorrectly gray out the Browse button when the robot server goes down when it was not down before. If the robot server is down when the Opentrons App first discovers the robot, it seems like things work correctly.

Expected behavior

As long as it looks like the update server is able to receive an ot2-system.zip file, the Browse button should be usable.

[SyntaxColoring]

Running through the above steps to reproduce again, I couldn't get the Browse button to gray out. There might be something else going on here.

I am positive that I've had the Browse button be grayed out and have "fixed it" by closing and reopening the Opentrons App, which shouldn't work.

[mcous]

This button's disable logic was previously broken (#5429) and fixed (#6483). The fix contained most of the "is this button disabled?" logic to a single function, via updateFromFileDisabledReason:

opentrons/app/src/redux/buildroot/selectors.ts

Lines 136 to 173 in 63eb764

	export const getBuildrootUpdateDisplayInfo: (
	state: State,
	robotName: string
	) => {
	autoUpdateAction: string
	autoUpdateDisabledReason: string | null
	updateFromFileDisabledReason: string | null
	} = createSelector(
	getRobotByName,
	state => getBuildrootRobot(state),
	state => getBuildrootUpdateVersion(state),
	(robot, currentUpdatingRobot, updateVersion) => {
	const robotVersion = robot ? getRobotApiVersion(robot) : null
	const autoUpdateType = getBuildrootUpdateType(robotVersion, updateVersion)
	const autoUpdateAction = autoUpdateType ?? UNAVAILABLE
	let autoUpdateDisabledReason = null
	let updateFromFileDisabledReason = null
	if (robot?.serverHealthStatus !== HEALTH_STATUS_OK) {
	autoUpdateDisabledReason = UPDATE_SERVER_UNAVAILABLE
	updateFromFileDisabledReason = UPDATE_SERVER_UNAVAILABLE
	} else if (
	currentUpdatingRobot !== null &&
	currentUpdatingRobot.name !== robot?.name
	) {
	autoUpdateDisabledReason = OTHER_ROBOT_UPDATING
	updateFromFileDisabledReason = OTHER_ROBOT_UPDATING
	} else if (autoUpdateType === null) {
	autoUpdateDisabledReason = NO_UPDATE_FILES
	}
	return {
	autoUpdateAction,
	autoUpdateDisabledReason,
	updateFromFileDisabledReason,
	}
	}
	)

This logic looks pretty robust to me, so I'm sort of scratching my head as to why you would see this behavior. Did you check what the tooltip said?

We've had stale data problems of this type in the discovery client before, so I wouldn't rule out the DC accidentally marking the update server's health as bad given some set of conditions

[SyntaxColoring]

Did you check what the tooltip said?

I did, but I didn't write it down, and I don't remember. :(

[SyntaxColoring]

The app has evolved a lot since this ticket was written. I'm assuming this is no longer an issue.