TLDR: no, an http request with a non-2xx response does not necessarily indicate a problem.
Our SDKs have mechanisms to notify you of when errors occur. The main ones are connection state and channel state. The connection will emit an event when it changes connection state, which you can listen for programmatically; if it goes into the `disconnected` or `failed` state the state change will include a `reason` which will explain why it moved to that state. In the `disconnected` state it will automatically retry after 15s. Channel state works analagously (with different states).
Another mechanism is client library logs emitted at the ERROR level, which in most libraries can be accessed programmatically using a custom log handler.
But an http request getting a non-2xx status code is not such a mechanism. There are a large number of possible reasons individual http requests may return an error, especially in the presence of an imperfect network connection, and only a small fraction of them represent an actual problem.
One example: when a token expires that was unable to do an online reauth in time, if using comet, the recv stream will be closed with a 401 status code and an errorinfo body with code 40142. This isn't an unexpected situation or anything which needs human investigation or intervention, it just triggers the library to try to obtain a new token and then resume the connection with it.
(Conversely many things which aren't actual problems won't show up as a non-2xx http request, eg an error sent as a protocol message down a websocket).
The protocol was not designed to avoid non-2xx responses except where there is a genuinely unexpected condition. Instead we've picked the most semantically-appropriate status code for each individual response. (Such as 401 in the case above of a token expiring - this is entirely expected, but 401 is the most semantically meaningful match for that situation).
So we would strongly recommend against monitoring the status codes of http requests to try to detect problems. Our recommendation is to use the built-in mechanisms of the SDKs, in particular connection state changes, for this purpose.