frontend: guard against null disabledProducts in Footer

[jcristau]

When the disabled-products API call errors, useAction returns { data: null }, which then propagated into state and caused "right-hand side of 'in' should be an object, got null" at render time. Default to an empty object so the in check stays valid.

This can happen e.g. on localdev if the self-signed cert for the public endpoint is rejected by the browser.

[Eijebong]

Thx

[Eijebong]

Somewhat unrelated but might be worth a follow up to set that to {} by default. I think it's not creating any issue because the only use is product.product in disabledProducts && disabledProducts[product.product].includes(pb.branch) and it behaves the same (and thus gets short circuited):

> "a" in []
false
> "a" in {}
false

[jcristau]

As a side note we may want some explicit message/marker in the UI when access to the public api doesn't work, like we have for admin. Before this patch it's a js type error, after this patch the footer with the automated releases status is just silently broken.

[Eijebong]

Yeah, should be fairly easy, just dupe the __heartbeat__ call for the backend to the public backend?

shipit/frontend/src/Main.jsx

Lines 95 to 127 in aff6975

	const [backendStatus, checkBackendStatus] = useAction(() =>
	axios.get('/__heartbeat__'),
	);
	useEffect(() => {
	if (isReady) {
	checkBackendStatus();
	}
	}, [isReady]);
	if (!isReady || backendStatus.loading) {
	return (
	<BrowserRouter>
	<Dashboard disabled>
	<Box style={{ textAlign: 'center' }}>
	<CircularProgress />
	</Box>
	</Dashboard>
	</BrowserRouter>
	);
	}
	if (backendStatus.error) {
	return (
	<BrowserRouter>
	<Dashboard disabled>
	<ErrorPanel
	error={`Error contacting Shipit backend: ${backendStatus.error.toString()}. Are you connected to the VPN?`}
	/>
	</Dashboard>
	</BrowserRouter>
	);
	}

Can probably factor a bit, and skip isReady since you don't need a token to check. (name is a bit misleading I guess, that has to do with the auth0 token being there and valid)