MqttCore.connect: return false instead of raising #249
Conversation
| self._logger.info("Performing sync connect...") | ||
| event = Event() | ||
| self.connect_async(keep_alive_sec, self._create_blocking_ack_callback(event)) | ||
| if not event.wait(self._connect_disconnect_timeout_sec): | ||
| self._logger.error("Connect timed out") | ||
| raise connectTimeoutException() | ||
| self._logger.warning("Connect timed out, will try to reconnect") |
There was a problem hiding this comment.
This is not really an error as the background_network_io will still try to reconnect later
There was a problem hiding this comment.
First of all, thanks for submitting this. I agree that the error behavior here is an unpleasant surprise and could be more intuitive and less error-prone.
I think your second code sample is missing an "raise_on_timeout=False" from the connect call, right?
I'm wondering if we could make a tweak to this though. Right now the solution involves two levels of calls and I feel like it would be clearer to the user (who at best will look at the code of the first connect()) if the behavioral change was limited to the first call. The two approaches would otherwise be equivalent.
So how about this?
- Undo the changes to mqtt_core's connect()
- Add a try block to the client's connect() that swallows connectTimeoutException if raiseOnTimeout is false, otherwise rethrows
In this way if the user says "what does raiseOnTimeout do?" they only need to follow a single call. Either way, the new (non-default though) contract for connect()'s result remains:
- True if connected
- False if not connected but will retry
- Exception if not connected and will not retry
One final thing, do Python doc strings allow for a sample section? If so, adding a sample (on the client connect()) showing this new behavior and how it simplifies usage would be a great addition.
|
You are completely right, it should be With regards to catching the exception in the client.connect call instead of in mqtt_core.connect, I think I would disagree as mqtt_core is the one initialising the resources and thus it should be the one to clean them. Also, it would be adding a third place where behaviours change and would become a bit messy. Otherwise I do agree it would be more readable the way you suggest. Can make the changes if you think are necessary though... |
Can you explain a bit further about the resource clean up? My impression from reading the code is that no cleanup behavior is modified whether the new parameter is true or false and all we're doing is clarifying the return value contract of connect(). How would the second version make cleanup not the responsibility of mqtt_core? |
|
That was some poor explanation on my side, apologies: what I mean is, if mqtt_core raises I did not make those changes part of this PR as that is more of an opinion on the semantics of what object is responsible for what. |
|
Greetings! Sorry to say but this is a very old issue that is probably not getting as much attention as it deserves. We encourage you to try V2 and if you find that this is still a problem, please feel free to open a new issue there. |
Issue #, if available: 248
Description of changes: When
MqttCore.connect_asyncsuccessfully returns when it is called fromMqttCore.connect,self._event_consumer.stop()is never called so neither isself._internal_async_client.stop_background_network_io(). This means that whenMqttCore.connect_asyncreturns andnot event.wait(self._connect_disconnect_timeout_sec) == Truethe call toMqttCore.connectwill raise an error, but the system might still connect to the broker as the background_network_io is still running. A side effect of this is, if the user tries to call the connect method when it "fails" like this:The daemon threads spawned by
self._start_workers()will be spawned again and thus duplicated.With these changes, the user will be able to do something like:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.