fix: Return proper error code on config-related startup errors.

[max-foss]

Well, my monitoring interprets that HTTP 200 as everything is well and if I somehow end up with an invalid config, I don't notice.

Quick fix to address that, didn't want to pollute the issue tracker with yet another issue first.

[max-foss]

Sorry for using actions as a test runner, don't have that set up locally.

[Koenkk]

Well, my monitoring interprets that HTTP 200 as everything is well and if I somehow end up with an invalid config

What kind of monitoring do you have? We have to be careful that this doesn't cause the addon to end-up in a restart loop (https://github.com/zigbee2mqtt/hassio-zigbee2mqtt/blob/c362dd90473c7e98cd8c10128bd54a74c9a0e28e/common/Dockerfile#L54)

[max-foss]

Hmm, good point.

Had a simple web check in Uptime Kuma that caught one failure-mode, but it's also just me being annoyed about this kind of behaviour:

Alternative we could add an endpoint that return OK or sth similar in body when it booted and has both a connection to the Zigbee stick and to the MQTT broker.

[Koenkk]

I think it depends on how you look at it, the onboarding page works fine, therefore I think returning 200 is correct. If we return 500 here you would end up in a restart loop disabling the ability to correct the config.

[max-foss]

Thanks for the quick feedback.

If it is so problematic in relation to other services, I will either find a way to make the full MQTT health_check work in Uptime Kuma or design a dedicated endpoint just for all kinds of HTTP health monitoring.

The latter would be its own PR.