Nope, what you stated is what I expected. And matches the behavior of nodes I have used. Thanks.
Just as an example, the BME280 sensor node tries to initialize the sensor, even if the sensor is not present. This generates (debug) errors. As a result as I am developing my own nodes, wanted to know what could or should be done. Really, specific to that node, it comes down to how the developer wrote the code.
There is a design issue here, there is a difference between the sensor not on the i2c bus because not connected physically, or a sensor that has failed at some point, and maybe dropped of the bus. I think for what I write, I will include a configuration option of how to handle the error reporting if the sensor is missing or non-responsive, and an option for when the sensor is initialized, at node load, or at node actual use.
Just to illustrate this design decision... Below is an example... I am not suggesting a change to the mysql node design...
The mysql node is another node that attempts/does connect to a db before it is ever invoked by message received. I don't think this always the best option all the time. I understand why a connection is held open, in the case of mysql there is true cost to opening and closing the connection per select/insert/delete, etc. queries. Pooling connections benefit, etc. are real issues. Adding a configuration option for the mysql node, to open and close connection per query, or explicit nodes that do open and close functions, thus not initialize and hold open a connection, provides node use flexibility, which I am a big fan of, providing user flexibility, when possible.