Disconnect without reconnect in rc13

Up until v2.0rc12 I sometimes had the issue with the (spurious) OutOfMemory error related to connection problems.
Since updating to rc13 last week, I did not find those issues anymore, but instead had the following:
02:09:14|pipeline| ERROR |pipeline_stages:_on_mqtt_discon | MQTTTransportStage: _on_mqtt_disconnect called: Paho returned rc==1 caused by None
02:09:14|pipeline| WARNI |pipeline_stages:_on_mqtt_discon | MQTTTransportStage: disconnection was unexpected
02:09:14|pipeline| ERROR |handle_exceptio:handle_backgrou | Exception caught in background thread.  Unable to handle.
02:09:14|pipeline| ERROR |handle_exceptio:handle_backgrou | ['azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None caused by Paho returned rc==1 caused by None\n']

From then on, the connection seemed to be dead with no more messages being sent.
Should this exception be handled by the user (me) or should the reconnect be done by the SDK?

Hi @oerpli
The reconnection should happen automatically, Are you able to privately share full logs with me?
Setting the logging level to INFO or even DEBUG would help.  I really only need to see the _on_mqtt_disconnected message onward.  There is a piece of code called the ReconnectStage which should detect this condition and reconnect.  It sound like this reconnection code isn't being triggered (or is failing) and I'd like to figure out why.
-Bert

I would like to share more, but that's all I have at the moment.
I logged my application with logging level INFO, but after my excerpt all remaining log was from my code.
I restarted the process today and changed the logging level to DEBUG - I will add more, if there is something in the log then.

Just noticed that the logging level of 3rd party code (the SDK) was set to WARNING when the bug above occurred. So not sure whether the IoT SDK emitted any more messages.
Since yesterday it's running with DEBUG but there haven't been any issues yet. I will post an update as soon as I know more.

Hi, i am having the same issue i will also try to catch something with debug

Experiencing the same error after my WebSocket api had a connection error:
MQTTTransportStage: _on_mqtt_disconnect called: Paho returned rc==1 caused by None
MQTTTransportStage: disconnection was unexpected
Exception caught in background thread.  Unable to handle.
['azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None caused by Paho returned rc==1 caused by None\n']

The code hangs and after keyboardinterrupt (hours later) we can see in which code segment:
 ^CTraceback (most recent call last):
  File "pull_data.py", line 288, in <module>
    db_data = write_data(socket.data, db_data, devices, now)
  File "pull_data.py", line 202, in write_data
    iothub_client.send_message(message)
  File "<string>", line 1, in send_message
  File "/home/user/anaconda3/lib/python3.7/site-packages/azure/iot/device/iothub/sync_clients.py", line 156, in send_message
    handle_result(callback)
  File "/home/user/anaconda3/lib/python3.7/site-packages/azure/iot/device/iothub/sync_clients.py", line 30, in handle_result
    return callback.wait_for_completion()
  File "/home/user/anaconda3/lib/python3.7/site-packages/azure/iot/device/common/evented_callback.py", line 67, in wait_for_completion
    self.completion_event.wait(*args, **kwargs)
  File "/home/user/anaconda3/lib/python3.7/threading.py", line 552, in wait
    signaled = self._cond.wait(timeout)
  File "/home/user/anaconda3/lib/python3.7/threading.py", line 296, in wait
    waiter.acquire()
KeyboardInterrupt

A more detailed log this time:
2019-11-28 14:17:49,353:INFO:Sending message to Hub...
2019-11-28 14:17:49,354:INFO:MQTTTransportStage(MQTTPublishOperation): publishing on devices/my-devices/messages/events/%24.ct=application%2Fjson&%24.ce=utf-8
2019-11-28 14:17:49,354:INFO:publishing on devices/my-devices/messages/events/%24.ct=application%2Fjson&%24.ce=utf-8
2019-11-28 14:18:14,871:ERROR:failed to receive on socket: [Errno 104] Connection reset by peer
2019-11-28 14:18:14,872:INFO:disconnected with result code: 1
2019-11-28 14:18:14,873:INFO:Forcing paho disconnect to prevent it from automatically reconnecting
2019-11-28 14:18:14,873:ERROR:MQTTTransportStage: _on_mqtt_disconnect called: Paho returned rc==1 caused by None
2019-11-28 14:18:14,874:INFO:ReconnectStage: disconnected, but not virtually connected.  Not triggering reconnect timer.
2019-11-28 14:18:14,874:WARNING:MQTTTransportStage: disconnection was unexpected
2019-11-28 14:18:14,874:ERROR:Exception caught in background thread.  Unable to handle.
2019-11-28 14:18:14,874:ERROR:['azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None caused by Paho returned rc==1 caused by None\n']
2019-11-28 14:18:14,874:INFO:Connection State - Disconnected
2019-11-28 14:18:14,874:INFO:Cleared all pending method requests due to disconnect

I keep encountering this error every few hours when running a script that sends device to cloud messages (250 devices, sequentially). Here is the full DEBUG level error log. I really need this to work on production level soon, so would love to hear an update or maybe some workaround. Thanks
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(MQTTPublishOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:MQTTTransportStage(MQTTPublishOperation): running
INFO:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage(MQTTPublishOperation): publishing on devices/devices/messages/events/%24.ct=application%2Fjson&%24.ce=utf-8
INFO:azure.iot.device.common.mqtt_transport:publishing on devices/devices/messages/events/%24.ct=application%2Fjson&%24.ce=utf-8
DEBUG:paho:Sending PUBLISH (d0, q1, r0, m2914), 'b'devices/devices/messages/events/%24.ct=application%2Fjson&%24.ce=utf-8'', ... (187 bytes)
DEBUG:azure.iot.device.common.mqtt_transport:_mqtt_client.publish returned rc=0
DEBUG:azure.iot.device.common.mqtt_transport:Waiting for response on MID: 2914
DEBUG:paho:Sending PINGREQ
DEBUG:paho:Sending PUBLISH (d1, q1, r0, m2914), 'b'devices/devices/messages/events/%24.ct=application%2Fjson&%24.ce=utf-8'', ... (187 bytes)
ERROR:paho:failed to receive on socket: [Errno 104] Connection reset by peer
INFO:azure.iot.device.common.mqtt_transport:disconnected with result code: 1
DEBUG:azure.iot.device.common.mqtt_transport:  File "/home/user/anaconda3/lib/python3.7/threading.py", line 890, in _bootstrap
    self._bootstrap_inner()
  File "/home/user/anaconda3/lib/python3.7/threading.py", line 926, in _bootstrap_inner
    self.run()
  File "/home/user/anaconda3/lib/python3.7/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/home/user/anaconda3/lib/python3.7/site-packages/paho/mqtt/client.py", line 3428, in _thread_main
    self.loop_forever(retry_first_connection=True)
  File "/home/user/anaconda3/lib/python3.7/site-packages/paho/mqtt/client.py", line 1782, in loop_forever
    rc = self.loop(timeout, max_packets)
  File "/home/user/anaconda3/lib/python3.7/site-packages/paho/mqtt/client.py", line 1177, in loop
    rc = self.loop_read(max_packets)
  File "/home/user/anaconda3/lib/python3.7/site-packages/paho/mqtt/client.py", line 1570, in loop_read
    return self._loop_rc_handle(rc)
  File "/home/user/anaconda3/lib/python3.7/site-packages/paho/mqtt/client.py", line 2230, in _loop_rc_handle
    self.on_disconnect(self, self._userdata, rc)
  File "/home/user/anaconda3/lib/python3.7/site-packages/azure/iot/device/common/mqtt_transport.py", line 186, in on_disconnect
    logger.debug("".join(traceback.format_stack()))

INFO:azure.iot.device.common.mqtt_transport:Forcing paho disconnect to prevent it from automatically reconnecting
DEBUG:azure.iot.device.common.mqtt_transport:Done forcing paho disconnect
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting _on_mqtt_disconnected in pipeline thread
ERROR:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage: _on_mqtt_disconnect called: Paho returned rc==1 caused by None
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage: on_disconnected
INFO:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage: disconnected, but not virtually connected.  Not triggering reconnect timer.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:PipelineRootStage: on_disconnected.  on_disconnected_handler=<function IoTHubPipeline.__init__.<locals>._on_disconnected at 0x7fe954945c20>
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting _on_disconnected in callback thread
WARNING:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage: disconnection was unexpected
ERROR:azure.iot.device.common.handle_exceptions:Exception caught in background thread.  Unable to handle.
ERROR:azure.iot.device.common.handle_exceptions:['azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None caused by Paho returned rc==1 caused by None\n']
INFO:azure.iot.device.iothub.sync_clients:Connection State - Disconnected
INFO:azure.iot.device.iothub.sync_clients:Cleared all pending method requests due to disconnect
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Timed SAS update for (devices,None)
INFO:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Generating new SAS token for (devices,None) that expires 3600 seconds in the future
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Canceling token update timer for (devices,None)
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Scheduling token update for (devices,None) for 3480 seconds in the future
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:sending token update notification for (devices, None)
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting on_sas_token_updated in pipeline thread
INFO:azure.iot.device.iothub.pipeline.pipeline_stages_iothub:UseAuthProviderStage: New sas token received.  Passing down UpdateSasTokenOperation.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:MQTTTransportStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage(UpdateSasTokenOperation): saving sas token and completing
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:MQTTTransportStage(UpdateSasTokenOperation): completing without error
DEBUG:azure.iot.device.iothub.pipeline.pipeline_stages_iothub:UseAuthProviderStage(UpdateSasTokenOperation): token update operation is complete
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Timed SAS update for (devices,None)
INFO:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Generating new SAS token for (devices,None) that expires 3600 seconds in the future
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Canceling token update timer for (devices,None)
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Scheduling token update for (devices,None) for 3480 seconds in the future
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:sending token update notification for (devices, None)
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting on_sas_token_updated in pipeline thread
INFO:azure.iot.device.iothub.pipeline.pipeline_stages_iothub:UseAuthProviderStage: New sas token received.  Passing down UpdateSasTokenOperation.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:MQTTTransportStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage(UpdateSasTokenOperation): saving sas token and completing
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:MQTTTransportStage(UpdateSasTokenOperation): completing without error
DEBUG:azure.iot.device.iothub.pipeline.pipeline_stages_iothub:UseAuthProviderStage(UpdateSasTokenOperation): token update operation is complete
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Timed SAS update for (devices,None)

@mounir-futurefacts - I think I see the problem here (and a hole in our testing).
INFO:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage: disconnected, but not virtually connected.  Not triggering reconnect timer.

Your first send_message call was causing the client to connect automatically, and that's the way it's supposed to work, but that code path wasn't setting the flag that triggered the automatic reconnect logic.
You should be able to work around this by calling connect() on the client object before you start sending messages.

@BertKleewein - thanks, this seems to be the problem indeed. I have not tested it with a single call to the connect() method, but since I updated my code yesterday to manually connect and reconnect every x messages it is now running for 24hrs straight with no problems.
You probably want to update the quickstarts (at least the simulated device quickstart which I used as a starting point for my project) to use the connect() method before sending messages. Created a pull request for the code that I used.

I saw the problem again using the connect() only on my init, do i need to connect() again after the error occurs or on each of the calls to the send_message?
Thanks in advance

Hi Miguel,
I am not calling connect() before each send_message call, but rather call disconnect() after each batch of messages (every minute) and then connect again before sending a new batch. You might try something like this for your own solution, where you preventively (dis)-connect after a batch of messages.
Mounir Hader
+31 613307367tel:+31 613307367 • mounir.hader<EMAIL_ADDRESS>Future Facts • Danzigerkade 19 • 1013 AP Amsterdam • www.futurefacts.nlhttps://www.futurefacts.nl • +31 20 581 02 20tel:+31205810220 • KvK 63663732
[LinkedIn]https://www.linkedin.com/company/future-facts/      [Facebook] https://www.facebook.com/futurefactsnl     [Twitter] https://twitter.com/futurefactsnl   [Instagram] https://www.instagram.com/futurefactsnl/
[Logo Future Facts] https://www.futurefacts.nl
Onderdeel van de Hot ITem Groep • Expert in Factbased Improvement
Wij geloven in wendbare, datagedreven organisaties die de concurrentie voorblijven door zich snel te kunnen aanpassen aan nieuwe ontwikkelingen. Alles wat wij doen heeft tot doel om de performance van mensen, afdelingen en organisaties onderscheidend te verbeteren. Dit doen wij samen met onze klanten, op basis van kwalitatief goede data en inzicht in de cruciale zaken.
From: Miguel<EMAIL_ADDRESS>Reply to: Azure/azure-iot-sdk-python<EMAIL_ADDRESS>Date: Wednesday, 4 December 2019 at 00:34
To: Azure/azure-iot-sdk-python<EMAIL_ADDRESS>Cc: Mounir Hader<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Azure/azure-iot-sdk-python] Disconnect without reconnect in rc13 (#399)
I saw the problem again using the connect() only on my init, do i need to connect() again after the error occurs or on each of the calls to the send_message?
Thanks in advance
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-iot-sdk-python/issues/399?email_source=notifications&email_token=ANS3WSN75XZFS6PFFUKUQMLQW3UFTA5CNFSM4JRE7XQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF3F5HQ#issuecomment-561405598, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANS3WSIIDGZA3IL5T52UPWDQW3UFTANCNFSM4JRE7XQQ.

Is this an issue that should be handled by the user (of the SDK) or by the SDK itself?
In case of the latter - is there a timeline when it will be done?

@oerpli - this _hould be done by the SDK.  Calling connect from the client is just a workaround and  only needs to be called one single time.  If you're not seeing a line in the log (level INFO) that says ReconnectStage: disconnected, but not virtually connected.  Not triggering reconnect timer. then your issue has a different cause.

@BertKleewein  - Hi, after running fine for 48 hours with the released V2 I got:
2019-12-19T13:06:15.223826117Z Traceback (most recent call last):
2019-12-19T13:06:15.223830512Z   File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
2019-12-19T13:06:15.223833200Z     self.run()
2019-12-19T13:06:15.223835405Z   File "/usr/lib/python3.6/threading.py", line 864, in run
2019-12-19T13:06:15.223837631Z     self._target(*self._args, **self._kwargs)
2019-12-19T13:06:15.223839747Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 3428, in _thread_main
2019-12-19T13:06:15.223841888Z     self.loop_forever(retry_first_connection=True)
2019-12-19T13:06:15.223844001Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 1782, in loop_forever
2019-12-19T13:06:15.223846164Z     rc = self.loop(timeout, max_packets)
2019-12-19T13:06:15.223848182Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 1177, in loop
2019-12-19T13:06:15.223850282Z     rc = self.loop_read(max_packets)
2019-12-19T13:06:15.223852358Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 1568, in loop_read
2019-12-19T13:06:15.223858128Z     rc = self._packet_read()
2019-12-19T13:06:15.223862615Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 2271, in _packet_read
2019-12-19T13:06:15.223865276Z     byte = self._sock_recv(1)
2019-12-19T13:06:15.223867305Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 660, in _sock_recv
2019-12-19T13:06:15.223869622Z     return self._sock.recv(bufsize)
2019-12-19T13:06:15.223875624Z AttributeError: 'NoneType' object has no attribute 'recv'

So for me this issue persist....

Hi guys,
Also observed this issue several times during our custom module development.
MQTTTransportStage: _on_mqtt_disconnect called: Paho returned rc==1 caused by None
MQTTTransportStage: disconnection was unexpected
Exception caught in background thread.  Unable to handle.
['azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None caused by Paho returned rc==1 caused by None\n']

Unfortunately (or luckily), cannot reproduce it now with  debug log level. Issue happens quite unpredictable and not on a regular basis. I will share logs when observe it again.

As a quick update: I added the .connect() and haven't had a single issue since the last restart (around mid December).

This is weird. Whenever I try to run receive_direct_method.py, it keeps disconnecting every few seconds.
Here's the log if it helps:
DEBUG:asyncio:Using selector: KqueueSelector
INFO:azure.iot.device.iothub.auth.sk_authentication_provider:Using Shared Key authentication for {ugv-a.azure-devices.net, ugv-black, None}
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting run_op in pipeline thread
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Creating pipeline executor
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:PipelineRootStage(SetAuthProviderOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:PipelineRootStage(SetAuthProviderOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(SetAuthProviderOperation): running
INFO:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Generating new SAS token for (ugv-black,None) that expires 3600 seconds in the future
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:Scheduling token update for (ugv-black,None) for 3480 seconds in the future
DEBUG:azure.iot.device.iothub.auth.base_renewable_token_authentication_provider:sending token update notification for (ugv-black, None)
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Already in pipeline thread for _on_sas_token_updated
INFO:azure.iot.device.iothub.pipeline.pipeline_stages_iothub:UseAuthProviderStage: New sas token received.  Passing down UpdateSasTokenOperation.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubHTTPTranslationStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubHTTPTranslationStage(UpdateSasTokenOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:HTTPTransportStage(UpdateSasTokenOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_http:HTTPTransportStage(UpdateSasTokenOperation): saving sas token and completing
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:UpdateSasTokenOperation: completing without error
DEBUG:azure.iot.device.iothub.pipeline.pipeline_stages_iothub:UseAuthProviderStage(UpdateSasTokenOperation): token update operation is complete
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetAuthProviderOperation: creating worker op of type SetIoTHubConnectionArgsOperation
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(SetIoTHubConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubHTTPTranslationStage(SetIoTHubConnectionArgsOperation): running
DEBUG:azure.iot.device.iothub.pipeline.pipeline_stages_iothub_http:Gateway Hostname not present. Setting Hostname to: None
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetIoTHubConnectionArgsOperation: creating worker op of type SetHTTPConnectionArgsOperation
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubHTTPTranslationStage(SetHTTPConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:HTTPTransportStage(SetHTTPConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_http:HTTPTransportStage(SetHTTPConnectionArgsOperation): got connection args
DEBUG:azure.iot.device.common.http_transport:creating a SSL context
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetHTTPConnectionArgsOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetIoTHubConnectionArgsOperation: Worker op (SetHTTPConnectionArgsOperation) has been completed
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetIoTHubConnectionArgsOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetAuthProviderOperation: Worker op (SetIoTHubConnectionArgsOperation) has been completed
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetAuthProviderOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting <azure.iot.device.common.evented_callback.EventedCallback object at 0x10da4ce10> in callback thread
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Creating callback executor
DEBUG:azure.iot.device.common.evented_callback:Callback completed with result None
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting run_op in pipeline thread
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:PipelineRootStage(SetAuthProviderOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:PipelineRootStage(SetAuthProviderOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(SetAuthProviderOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetAuthProviderOperation: creating worker op of type SetIoTHubConnectionArgsOperation
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(SetIoTHubConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(SetIoTHubConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(SetIoTHubConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(SetIoTHubConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(SetIoTHubConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(SetIoTHubConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetIoTHubConnectionArgsOperation: creating worker op of type SetMQTTConnectionArgsOperation
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(SetMQTTConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(SetMQTTConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(SetMQTTConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(SetMQTTConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(SetMQTTConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(SetMQTTConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(SetMQTTConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(SetMQTTConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(SetMQTTConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(SetMQTTConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(SetMQTTConnectionArgsOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:MQTTTransportStage(SetMQTTConnectionArgsOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage(SetMQTTConnectionArgsOperation): got connection args
INFO:azure.iot.device.common.mqtt_transport:creating mqtt client
INFO:azure.iot.device.common.mqtt_transport:Creating client for connecting using MQTT over TCP
DEBUG:azure.iot.device.common.mqtt_transport:creating a SSL context
DEBUG:azure.iot.device.common.mqtt_transport:Created MQTT protocol client, assigned callbacks
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetMQTTConnectionArgsOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetIoTHubConnectionArgsOperation: Worker op (SetMQTTConnectionArgsOperation) has been completed
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetIoTHubConnectionArgsOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetAuthProviderOperation: Worker op (SetIoTHubConnectionArgsOperation) has been completed
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:SetAuthProviderOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting <azure.iot.device.common.evented_callback.EventedCallback object at 0x10da77990> in callback thread
DEBUG:azure.iot.device.common.evented_callback:Callback completed with result None
INFO:azure.iot.device.iothub.aio.async_clients:Connecting to Hub...
DEBUG:azure.iot.device.iothub.pipeline.iothub_pipeline:Starting ConnectOperation on the pipeline
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting run_op in pipeline thread
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:PipelineRootStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:PipelineRootStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): blocking
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(ConnectOperation): passing to next stage.
 Calling on_connected_handler
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting _on_connected in callback thread
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_mqtt:completing connect op
INFO:azure.iot.device.iothub.aio.async_clients:Connection State - Connected
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:ConnectOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): op succeeded.  Unblocking queue
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): unblocking and releasing queued ops.
INFO:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): processing 0 items in queue
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): unblock is complete
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting on_complete in callback thread
DEBUG:azure.iot.device.common.async_adapter:Callback completed with result None
INFO:azure.iot.device.iothub.aio.async_clients:Successfully connected to Hub
Press Q to quit
INFO:azure.iot.device.iothub.aio.async_clients:Enabling feature:methods...
DEBUG:azure.iot.device.iothub.pipeline.iothub_pipeline:enable_feature methods called
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting run_op in pipeline thread
INFO:azure.iot.device.iothub.aio.async_clients:Waiting for method request...
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:PipelineRootStage(EnableFeatureOperation): running
INFO:azure.iot.device.iothub.aio.async_clients:Waiting for method request...
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:PipelineRootStage(EnableFeatureOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(EnableFeatureOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:UseAuthProviderStage(EnableFeatureOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(EnableFeatureOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:TwinRequestResponseStage(EnableFeatureOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(EnableFeatureOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:CoordinateRequestAndResponseStage(EnableFeatureOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(EnableFeatureOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:EnableFeatureOperation: creating worker op of type MQTTSubscribeOperation
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:IoTHubMQTTTranslationStage(MQTTSubscribeOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(MQTTSubscribeOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(MQTTSubscribeOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(MQTTSubscribeOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(MQTTSubscribeOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(MQTTSubscribeOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(MQTTSubscribeOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(MQTTSubscribeOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(MQTTSubscribeOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(MQTTSubscribeOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(MQTTSubscribeOperation): Creating timer
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(MQTTSubscribeOperation): Sending down
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(MQTTSubscribeOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:MQTTTransportStage(MQTTSubscribeOperation): running
INFO:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage(MQTTSubscribeOperation): subscribing to $iothub/methods/POST/#
INFO:azure.iot.device.common.mqtt_transport:subscribing to $iothub/methods/POST/# with qos 1
DEBUG:paho:Sending SUBSCRIBE (d0, m1) [(b'$iothub/methods/POST/#', 1)]
DEBUG:azure.iot.device.common.mqtt_transport:_mqtt_client.subscribe returned rc=0
DEBUG:azure.iot.device.common.mqtt_transport:Waiting for response on MID: 1
DEBUG:paho:Received SUBACK
INFO:azure.iot.device.common.mqtt_transport:suback received for 1
DEBUG:azure.iot.device.common.mqtt_transport:Response received for recognized MID: 1 - triggering callback
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting on_subscribed in pipeline thread
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage(MQTTSubscribeOperation): SUBACK received. completing op.
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:MQTTSubscribeOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(MQTTSubscribeOperation): Cancelling timer
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:EnableFeatureOperation: Worker op (MQTTSubscribeOperation) has been completed
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:EnableFeatureOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting on_complete in callback thread
DEBUG:azure.iot.device.common.async_adapter:Callback completed with result None
INFO:azure.iot.device.iothub.aio.async_clients:Successfully enabled feature:methods
INFO:azure.iot.device.iothub.aio.async_clients:Waiting for method request...
INFO:azure.iot.device.common.mqtt_transport:disconnected with result code: 1
DEBUG:azure.iot.device.common.mqtt_transport:  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 890, in _bootstrap
    self._bootstrap_inner()
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 926, in _bootstrap_inner
    self.run()
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.7/site-packages/paho/mqtt/client.py", line 3428, in _thread_main
    self.loop_forever(retry_first_connection=True)
  File "/usr/local/lib/python3.7/site-packages/paho/mqtt/client.py", line 1782, in loop_forever
    rc = self.loop(timeout, max_packets)
  File "/usr/local/lib/python3.7/site-packages/paho/mqtt/client.py", line 1177, in loop
    rc = self.loop_read(max_packets)
  File "/usr/local/lib/python3.7/site-packages/paho/mqtt/client.py", line 1570, in loop_read
    return self._loop_rc_handle(rc)
  File "/usr/local/lib/python3.7/site-packages/paho/mqtt/client.py", line 2230, in _loop_rc_handle
    self.on_disconnect(self, self._userdata, rc)
  File "/usr/local/lib/python3.7/site-packages/azure/iot/device/common/mqtt_transport.py", line 186, in on_disconnect
    logger.debug("".join(traceback.format_stack()))

INFO:azure.iot.device.common.mqtt_transport:Forcing paho disconnect to prevent it from automatically reconnecting
DEBUG:azure.iot.device.common.mqtt_transport:Done forcing paho disconnect
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting _on_mqtt_disconnected in pipeline thread
ERROR:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage: _on_mqtt_disconnect called: Paho returned rc==1 caused by None
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:MQTTTransportStage(DisconnectedEvent): pushing event up to OpTimeoutStage
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(DisconnectedEvent): pushing event up to RetryStage
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(DisconnectedEvent): pushing event up to ConnectionLockStage
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(DisconnectedEvent): pushing event up to AutoConnectStage
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(DisconnectedEvent): pushing event up to ReconnectStage
INFO:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage: disconnected but virtually connected.  Triggering reconnect timer.
 Calling on_disconnected_handler
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting _on_disconnected in callback thread
WARNING:azure.iot.device.common.pipeline.pipeline_stages_mqtt:MQTTTransportStage: disconnection was unexpected
INFO:azure.iot.device.iothub.aio.async_clients:Connection State - Disconnected
ERROR:azure.iot.device.common.handle_exceptions:Exception caught in background thread.  Unable to handle.
INFO:azure.iot.device.iothub.aio.async_clients:Cleared all pending method requests due to disconnect
ERROR:azure.iot.device.common.handle_exceptions:['azure.iot.device.common.transport_exceptions.ConnectionDroppedError: None caused by Paho returned rc==1 caused by None\n']
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting on_reconnect_timer_expired in pipeline thread
INFO:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage: reconnect timer expired.  Sending connect op down
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage: Sending connect operation down
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:AutoConnectStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): blocking
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:RetryStage(ConnectOperation): passing to next stage.
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(ConnectOperation): running
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:OpTimeoutStage(ConnectOperation): passing to next stage.
 Calling on_connected_handler
DEBUG:azure.iot.device.common.pipeline.pipeline_thread:Starting _on_connected in callback thread
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_mqtt:completing connect op
DEBUG:azure.iot.device.common.pipeline.pipeline_ops_base:ConnectOperation: completing without error
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): op succeeded.  Unblocking queue
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): unblocking and releasing queued ops.
INFO:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): processing 0 items in queue
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ConnectionLockStage(ConnectOperation): unblock is complete
DEBUG:azure.iot.device.common.pipeline.pipeline_stages_base:ReconnectStage: reconnect successful
INFO:azure.iot.device.iothub.aio.async_clients:Connection State - Connected

@msjaber - From this log, I see the disconnects and I see the library reconnecting.  It looks like the python library is behaving as it should given what it can control.  If the library sees the connection drop, it tries to reconnect.
I don't see anything in that log showing a cause for the frequent disconnects.  It looks like the library is reconnecting successfully but something else is causing the connection to drop again, which causes the library to reconnect, and so on.  The thing causing the connection to drop could be anything: a buggy device driver, a loose cable in your PC, a misbehaving switch or cable at any of the dozens of hops between your location and the Azure data center, or even, gasp, a problem with one of the Azure machines which  backs your IoTHub instance.
The other thing, which comes up more often than you might think, is when 2 different clients are connecting using the same device credentials.  If there's 2 processes both trying to connect as the same device, they can ping-pong back and forth.  One process would connect, which causes the second process to disconnect, then when the second process reconnects, it causes the first process to disconnect, and so on.
The library is doing its best to remain connected, but something else about the network is causing this extra traffic.  The reconnect code is currently very aggressive, meaning it will always try to reconnect fairly soon after the disconnect (I think 10 seconds).  There's no notion (yet) of backing off on re-connection frequency o possibly even giving up after some number of failures.

I am also having this issue. 3x Python modules on the same device all experienced this issue around the same time, which was after around 3 days of being Up. I'm using IoT Edge for what its worth. Error from the logs of one of these modules below:
MQTTTransportStage: _on_mqtt_disconnect called: Paho returned rc==1 caused by None
ReauthorizeConnectionOperation: completing with error Paho returned rc==1 caused by None
ConnectionLockStage(ReauthorizeConnectionOperation): op failed.  Unblocking queue with error: Paho returned rc==1 caused by None
ConnectionLockStage(ReauthorizeConnectionOperation): failing MQTTPublishOperation op because of error
MQTTPublishOperation: completing with error Paho returned rc==1 caused by None
SendOutputEventOperation: completing with error Paho returned rc==1 caused by None
UpdateSasTokenOperation: completing with error Paho returned rc==1 caused by None
UseAuthProviderStage(UpdateSasTokenOperation): token update operation failed.  Error=Paho returned rc==1 caused by None
Exception caught in background thread.  Unable to handle.
Callback completed with error Paho returned rc==1 caused by None
azure.iot.device.common.transport_exceptions.ConnectionDroppedError: Paho returned rc==1 caused by None
['azure.iot.device.common.transport_exceptions.ConnectionDroppedError: Paho returned rc==1 caused by None\n']
Unexpected error Lost connection to IoTHub caused by Paho returned rc==1 caused by None
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/azure/iot/device/iothub/aio/async_clients.py", line 29, in handle_result
    return await callback.completion()
  File "/usr/local/lib/python3.7/site-packages/azure/iot/device/common/async_adapter.py", line 93, in completion
    return await self.future
azure.iot.device.common.transport_exceptions.ConnectionDroppedError: Paho returned rc==1 caused by None

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "./main.py", line 52, in <module>
    asyncio.run(main())
  File "/usr/local/lib/python3.7/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.7/asyncio/base_events.py", line 583, in run_until_complete
    return future.result()
  File "./main.py", line 43, in main
    await asyncio.gather(sensor_listener(module_client))
  File "./main.py", line 39, in sensor_listener
    await module_client.send_message_to_output(message, "output")
  File "/usr/local/lib/python3.7/site-packages/azure/iot/device/iothub/aio/async_clients.py", line 429, in send_message_to_output
    await handle_result(callback)
  File "/usr/local/lib/python3.7/site-packages/azure/iot/device/iothub/aio/async_clients.py", line 31, in handle_result
    raise exceptions.ConnectionDroppedError(message="Lost connection to IoTHub", cause=e)
azure.iot.device.exceptions.ConnectionDroppedError: Lost connection to IoTHub caused by Paho returned rc==1 caused by None

From reading this thread, I found this PR for samples: https://github.com/Azure-Samples/azure-iot-samples-python/pull/18
Noticed that in the PR (which is still open) he is calling client.connect() without using await, whereas I was using await. I will try without the await to see if anything changes.

@BertKleewein - Hi, after running fine for 48 hours with the released V2 I got:
2019-12-19T13:06:15.223826117Z Traceback (most recent call last):
2019-12-19T13:06:15.223830512Z   File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
2019-12-19T13:06:15.223833200Z     self.run()
2019-12-19T13:06:15.223835405Z   File "/usr/lib/python3.6/threading.py", line 864, in run
2019-12-19T13:06:15.223837631Z     self._target(*self._args, **self._kwargs)
2019-12-19T13:06:15.223839747Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 3428, in _thread_main
2019-12-19T13:06:15.223841888Z     self.loop_forever(retry_first_connection=True)
2019-12-19T13:06:15.223844001Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 1782, in loop_forever
2019-12-19T13:06:15.223846164Z     rc = self.loop(timeout, max_packets)
2019-12-19T13:06:15.223848182Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 1177, in loop
2019-12-19T13:06:15.223850282Z     rc = self.loop_read(max_packets)
2019-12-19T13:06:15.223852358Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 1568, in loop_read
2019-12-19T13:06:15.223858128Z     rc = self._packet_read()
2019-12-19T13:06:15.223862615Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 2271, in _packet_read
2019-12-19T13:06:15.223865276Z     byte = self._sock_recv(1)
2019-12-19T13:06:15.223867305Z   File "/usr/local/lib/python3.6/dist-packages/paho/mqtt/client.py", line 660, in _sock_recv
2019-12-19T13:06:15.223869622Z     return self._sock.recv(bufsize)
2019-12-19T13:06:15.223875624Z AttributeError: 'NoneType' object has no attribute 'recv'

So for me this issue persist....

Hi @BertKleewein , still getting exactly this issue with v2.0.1. I tried to run the pipeline with debug level logging. The problem is that it is too verbose. I send at least 30 messages per second via device messaging, and it normally takes a good couple of hours for the issue to occur.
In the code I check the "connected" property of the client before sending, and if not connected I call connect. Problem is that in the error state the client still reports that it is connected.

2.1.1 has fixes for issues where client.connected was set incorrectly.  This issue should be resolved.  If you discover any new connection problems after upgrading to 2.1.1, please open a new issue.

@BertKleewein, @oerpli, @MiguelCHR, @mounir-futurefacts, @LouanDuToitS3, @Kyrylo-Iarosh, @msjaber, @lokijota, @elliotchaim, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey


Problem with intensity pro

Hi. I have an Intensity pro 4k on an intel i3 with linux mint 17.1 x64.
I am trying to capture from HDMI input and export to .nut file but all I get is the screen with vertical color lines. When using media express i can see the capture just fine.
This is what i use:
./bmdcapture -m 13 -C 0 -V 3 -A 2 -v -F nut -f test.nut
I am somewhat of a beginner in all this and would greatly appreciate some help.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26894924-problem-with-intensity-pro?utm_campaign=plugin&utm_content=tracker%2F256764&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F256764&utm_medium=issues&utm_source=github).

Vertical color lines mean that the input is wrong please check you are
using the right input.
On Wed, Sep 23, 2015 at 3:13 PM, S1ri0S<EMAIL_ADDRESS>wrote:

Hi. I have an Intensity pro 4k on an intel i3 with linux mint 17.1 x64.
I am trying to capture from HDMI input and export to .nut file but all I
get is the screen with vertical color lines. When using media express i can
see the capture just fine.
This is what i use:
./bmdcapture -m 13 -C 0 -V 3 -A 2 -v -F nut -f test.nut
I am somewhat of a beginner in all this and would greatly appreciate some
help.
—
Reply to this email directly or view it on GitHub
https://github.com/lu-zero/bmdtools/issues/65.

Many thanks for the fast reply.
When you say input do you mean there is something wrong with the command params?
-C 0 is correct (I only have 1 capture card) and -m 11 is also correct since video input is
1080p59.94. HDMI cable is connected to hdmi out of a laptop on one side and to the hdmi in of my intensity pro on the other. Also in media express I can see the capture perfectly well.
Thanx in advance

It is quite strange -V 3 is hdmi so it should be ok.
On Wed, Sep 23, 2015 at 4:27 PM, S1ri0S<EMAIL_ADDRESS>wrote:

Many thanks for the fast reply.
When you say input do you mean there is something wrong with the command
params?
-C 0 is correct (I only have 1 capture card) and -m 11 is also correct
since video input is
1080p59.94. HDMI cable is connected to hdmi out of a laptop on one side
and to the hdmi in of my intensity pro on the other. Also in media express
I can see the capture perfectly well.
Thanx in advance
—
Reply to this email directly or view it on GitHub
https://github.com/lu-zero/bmdtools/issues/65#issuecomment-142618249.

Hey Guys,
got exactly the same problem. Any solution found ?
With my Macbook it works just fine (i can capture with bmdcapture) but as soon as i connect my Lenovo notebook i can not (i checked all parameters). In media express everything is displayed good.

Okay Guys i probably found the soloutin.
I haven´t had activated the "ycbcr-option" for my laptop. After activating, there were no more color lines for me.
Maybe thats the problem as well for S1ri0S.

@S1ri0S is the problem still there for you?

I'm sorry for the lack of feedback on this, it completely fell off my mind.
As it turns out mine was a hardware problem. Once i fixed it everything worked like a charm.
Thanx a lot.


use vendored dart sdk; check the expected version of flutter

don't add the vendored dart sdk to the path before starting flutter_tools
within the tool, make sure that all the dart process calls go through the vendored dart sdk (fix @jason-simmons's issue from yesterday)

and

when running flutter upgrade, show what flutter dir we're upgrading (in case the dir is surprising to the user)
when running flutter, make sure that if the current dir is a flutter repo, it's the same one as running process (fix https://github.com/flutter/flutter/issues/3330)

LGTM

This is great. In the future we should also augment this so that flutter doctor detects when the "dart" on the path isn't the same (version? exact path?) as the one that the tool will use, and warn about that.

walk up the directory tree checking to see if we're in a subdirectory of a flutter checkout, too

Which I do all the time, when testing the gallery :)

In the future we should also augment this so that flutter doctor detects when the "dart" on the path isn't the same (version? exact path?)

I actually had that in an earlier version of this PR. I took it out because I thought it would often be a false positive - we'd be warning frequently about something that was often not an issue.

It could just be a light hint or something. It's definitely something that trips people up regularly. I'd say we see someone get tripped up by this maybe two or three times a month.

Mostly I want it so that it appears in the bug when they file an issue with all the doctor output. :-)

Makes sense; it would probably be best called out as an fyi or something.


Use latestMajor .NET SDK

This will work on AppVeyor when the latest dotnet-install.sh file is released.


[5.7][Reflection] Gracefully handle reflection sections with bad sizes.

Cherry-pick https://github.com/apple/swift/pull/58770 to release/5.7.
When a reflection section has a size that only fits a partial record, we detect it, log an error, and abort. However, things like Remote Mirror need to be robust to bad data, so instead handle this by terminating iteration at the last full record.
rdar://91954103
(cherry picked from commit 5d1f63597bd210b198892368bdc6e720eb9c4bd5)

@swift-ci please test


GAS_PRICE_TOO_LOW vs GAS_LIMIT_TOO_LOW - Incorrect error being thrown

https://github.com/FuelLabs/fuels-ts/blob/f6fb12b7fbc5c4ef4ed0b7471ae6749468b84a96/packages/providers/src/provider.ts#L479C4-L489C6
The error being thrown is switched upside down here

Good catch 🦊


Any reason why cysteine is ommitted by default in ProteinMPNN? Or is that just an accident?

Hi,
I noticed the AA Cysteine is omitted by default in the ProteinMPNN design in dl_interface_design.py
parser.add_argument( "-omit_AAs", type=str, default='CX', help='A string of all residue types (one letter case-insensitive) that you would not like to use for design. Letters not corresponding to residue types will be ignored (default: CX)' )
https://github.com/nrbennet/dl_binder_design/blob/bfab591db9a70c9c4eaf449c30ce4a1edcb7c989/mpnn_fr/dl_interface_design.py#L64C1-L64C58
Was this left there by accident or is there a reason for this?
Thanks

Cysteines can yield poorly behaved proteins in some systems so we exclude it by default. Feel free to enable them in your design runs!


update description research team

Thanks for the PR. The content is integrated into another PR that follows soon.


Add import warning, and change a few line breaks around

Codecov Report

Merging #301 (9ddbbab) into master (c1a53f3) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #301   +/-   ##
=========================================
  Coverage     75.85%   75.85%
  Complexity      936      936
=========================================
  Files           105      105
  Lines          2936     2936
  Branches        394      394
=========================================
  Hits           2227     2227
  Misses          601      601
  Partials        108      108

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1a53f3...9ddbbab. Read the comment docs.


Added patches, cleanup

Added patches to allow TCPGecko kern access in any process.
Removed half-implemented OS versions, they where super old.
Minor code cleanup.

lgtm


I2C over hard-coded /dev/i2c-1 not working

I tested a PCA9685 with chip-io (master branch) and noticed that nothing was happening using the johnny-five example. It looks like errors are just consumed in i2c.js so there's no way of knowing unless debugging (headless chip, used node --inspect flag with devtools from remote PC). Maybe a better approach when encountering errors would be to emit an error event instead of throwing or ignoring? I noticed that chip-io.js uses a hard-coded 1 for the bus value in /dev/i2c-1 here and here, but a ls /dev only shows i2c-0 and i2c-2 (Linux 4.4.11-ntc).
@rwaldron I'm trying to understand what the proper way to pass in the bus identifier when using the johnny-five API/Board.i2c functions for boards that support more than one I2C bus?

Platform specific bus property support needs to be handled by the IO Plugin—all Johnny-Five does is forward the options passed to the component class constructor, through to the the i2cConfig(...) call.

What version of Node.js is on the Chip?

nvm, I see that this project points to the nodesource install instructions—very smart.

I just found this: https://github.com/xtacocorex/CHIP_IO/issues/11

@ugate This should allow you to specify the bus as shown in the following:
var a = new five.Servo({
  bus: 1,
  address: 0x40,
  controller: "PCA9685",
  pin: 0,
});

@rwaldron Thanks for the update! I noticed the same thing on #9. What threw me off is the docs that state that Board.i2cConfig([milliseconds]) takes an optional millisecond parameter rather than an object of options. Should the docs be updated to reflect an options object instead?

@ugate it would be awesome if you could submit a pull request to the Johnny Five docs your Board.i2cConfig([milliseconds]) observation.

@sandeepmistry done :+1:


SCC Report Summary page

Background
The SCC report has recently been streamlined and a lengthy intro section has been replaced by a short summary page. This ticket aims to save time for Admins by automating some of the content; the rest will require manual population.
User Story
As an Admin, I would like the SCC summary page to be auto-populated where possible so that I can save time.
Feature(s) Description

[ ] Create a Word download as per the format attached
[ ] Auto-populate the fields according to this Miro board
[ ] Add a new link to the Reports menu as below

[SCC Summary page.docx](https://api.zenhub.com/attachedFiles/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBOHIrQnc9PSIsImV4cCI6bnVsbCwicHVyIjoiYmxvYl9pZCJ9fQ==--a6cde520a6d70b0820dde1c4523422fc61e7e125/SCC%20Summary%20page.docx)
Acceptance Criteria
It's done when Admins can produce an SCC summary page at the click of a button.
Definition of Done

[ ] User stories/acceptance criteria met
[ ] Internal reviews passed (feedback actioned)
[ ] User testing passed
[ ] Relevant technical documentation updated
[ ] User guidance updated
[ ] Deployed and merged without errors

User Testing Steps
Specify for users what is being tested (but not how to test it.)
Feature Champion
Nick

Hey team! Please add your planning poker estimate with Zenhub @drieJAC @HalcyonJAC @tomlovesgithub @warrensearle @KoWeiJAC

https://github.com/user-attachments/assets/08b8ce44-52c4-468c-a81c-aab5f9c1195e


Request: Kindly create examples with Mesh::part_dual and Mesh::part_nodal methods

Hi,
I'm really excited to use metis-rs for my CFD code.
I think it would be amazing if a few small examples were given with the library for the part_dual and part_nodal methods, since they're the most used methods in metis, and users having access to some simple test cases will help them use the library correctly.
I will try to see if I can create the examples on my own. And if  I'm successful, I will submit them for metis-rs.
Thanks!
Here are a few examples using Fortran interface to metis that give a small example mesh, and partition it:

https://ivan-pi.github.io/fmetis/sourcefile/test_partmeshnodal1.f90.html
https://ivan-pi.github.io/fmetis/sourcefile/test_partmeshnodal2.f90.html

That's a very good idea. Not sure when we will have time to do this but we will try to provide it.

@cedricchevalier19 thanks!
The examples are actually conceptually simple.
We just have two arrays, eptr for element pointers, and eind for element indices.
All anyone has to do, is send them to metis as arguments to either part_dual or part_nodal methods.
    ! 0---1---4---6
    ! | 0 | 1 | 2 |
    ! 3---2---5---7

    eptr = [0,4,8,12]
    eind = [0,1,2,3,1,4,5,2,4,6,7,5]


GH: Proposal to add type-hinting on Extend Speckle Object

Working on the Revit Opening Schema nodes, I was trying different ways of creating voids in walls and bumped into a smaller edge-case.
When trying to Extend an existing object, such as a Wall, it is not possible to overwrite the existing class members, as the type will not match with the generic object we're using as input.

So it is currently impossible to add a new element (whatever that is) to any existing Revit object received from Revit.
This could be solved with a similar approach to the Python and C# node, where the user can (if they want/need to), define exactly the type of input it should be.

For Base objects this would have no effect, but would enable to update things from grasshopper that are currently only doable by code.

Closing this, we can re-open if we deem it necessary.


Mailbox tuning

This PR implements the same mailbox tweak as I did on the Kotlin version.
TLDR, it maintains an atomic message counter for system messages.
So instead of asking the backing queue for empty state, it checks the counter.
This raised throughput from 80 to 90 mil (ish)
Is Server GC True
Dispatcher              Elapsed         Msg/sec
300<PHONE_NUMBER>0
400<PHONE_NUMBER>2
500<PHONE_NUMBER>5
600<PHONE_NUMBER>3
700<PHONE_NUMBER>0
800<PHONE_NUMBER>0
900<PHONE_NUMBER>2

ps. also some number tweaking in the inprocbenchmark for more consistent numbers

meh. apparently I was in my router-refactor branch when creating the new branch..

Also updated the mailbox to bounded mailbox, as we use that in the Go benchmark too.
This leads to the following stats:
Dispatcher              Elapsed         Msg/sec
300<PHONE_NUMBER>2
400<PHONE_NUMBER>27
500<PHONE_NUMBER>23
600<PHONE_NUMBER>07
700<PHONE_NUMBER>00
800<PHONE_NUMBER>23
900<PHONE_NUMBER>00

I also did some testing before this, netstandard 2.0 bumps perf by ~1.4 times.
if this still applies to the above numbers, it would bring us up to 175 mil msg/sec.


Back to basics : FreeCodeCamp - Machine Learning with Python Certification

Finish FreeCodeCamp - Machine Learning with Python

Migrated on another repository to handle global projects

Migrated on another repository to handle global projects


b2 workflow needs option for stdlib

Right now, it's impossible to run a b2 job with stdlib=libc++, as an example.

Mmm... Yes. We need that option.
Doesn't extra args work for now?
https://github.com/alandefreitas/cpp-actions/blob/3507d049fa58363fd14aac8dfcf32732e54cc782/b2-workflow/action.yml#L157


feat: adds position and sort args to artwork click

The type of this PR is: Feature
Re: FX-2545
Description

PR Checklist (tick all before merging)

[x] If I've added a new file to the tree I've exported it from the common index.ts
[x] I've added comments with examples for any new interfaces or helpers and ensured that they're in the docs
[x] No platform-specific terminology has been used outside of click and tap (platform is inferred by the DB storing events)

:rocket: PR was released in v1.69.0 :rocket:

:rocket: PR was released in v1.69.0 :rocket:


[Vmware/NGC] Fix for List Snapshot issue #345

What this PR does / why we need it:
NGC plugin go not list snapshots in vmware client. RCA is when there is snaphot creation results in error , adding this snaphot in to list is resul in java exception as some of the fileds are not present.
Fix is to check if the status of snapshot is eroor then do not add that in the sanpshot list.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #345
testing Notes :
Tested with mutiple snaphots and when snapshots having erro status.
log snippet below
Feb 03, 2020 3:37:24 PM org.opensds.vmware.ngc.adapters.opensds.OpenSDS listSnapshot
INFO: OpenSDS Snapshot List: [SnapshotMO [name=test200130152031662, id=5f6f3427-480e-4a25-bdb3-118f8367c449, healthStatus=available, capacity=1073741824, parentID=49c7ea7d-533b-43ae-b917-ab9297453165, timeStamp=2020-01-30T15:20:34]  [name=test200130151854618, id=3abb0385-4b03-4af9-a6d2-298263d9f203, healthStatus=error,  timeStamp=2 020-01-30T15:20:34]]

One doubt, only successfully created snapshots should be shown or all snapshots should be shown
Hope we do similar way as we do for volume listing

One doubt, only successfully created snapshots should be shown or all snapshots should be shown
Hope we do similar way as we do for volume listing

Only successfully created snapshots, basically the available snaphots which can be used for recovery.

LGTM

@NajmudheenCT how the user will come to know, there is an error in the snapshot? should we not show the status in the front end?
Pls check!

Thanks for noticing the status field. As of now we have issue to show the status in UI. I will create an issue for this. This fix is required as of now bcause without fix if there is any snapshot with error , no snapshots is howed in UII .

@NajmudheenCT please add the issue # here

@NajmudheenCT please add the issue # here

https://github.com/opensds/nbp/issues/354


Is the code for the llama part complete?

Is the code for the llama part complete?
Is the code ECoFLaP used on LLM provided?

Yes. Please see https://github.com/ylsung/ECoFLaP/tree/main/LLaMA


torch

i use the latest version and hasTorchState sets to true but when trying to get it its false


Extension - Recheck Kodadot NFT

Version test: http://<IP_ADDRESS>:8900/s/qaDFLRYHcxY8jBs
Validation passed.

Show image collection OG

Re-check other collection, transfer NFT

Install, Upgrade version


32 particles in great lakes water needs citation

I think it will just be to Austin and Steve's citation, but we need a super scripted citation for this one. Otherwise it kind of looks like the citation for the following fact is holds for both.

And I think there's already a preliminary citation in place in the list for that, just not with the journal details.

Both blurbs are for Austin's paper, right?

If so, should we (to be consistent) put a citation for both the oysters and mussels?
I was originally just putting one citation per "box".

So just to clarify @eread-usgs .... citation 3 in your screenshot is Austin and Steve's paper. Do you want the 3 to show up in both factoids? Or, should the >13,000 factoid have a different reference

@eread-usgs I'm going to close this issue, and open one that specifically numbers the references at the bottom. If you still think this issue is active, please reopen.


@joeyAghion => [Recaptcha] Refactor to avoid race condition

Fixes https://sentry.io/organizations/artsynet/issues/1048199288/?project=28316&query=is%3Aunresolved&statsPeriod=14d
There seems to be some sort of race condition going on where the onload is being executed before the script finishes loading with the async tag. I believe window.onload should wait for those so I'm not 100% sure I can logically trace the race condition, but it seems to be happening a fair bit.
This refactors it slightly to preserve the behavior (which I was wondering- we load the lib on every page but only execute something on the homepage?), but in a way that might be more explicit and avoid a race condition.
I wasn't sure how to test locally that the reCaptcha is actually working, but I was able to verify that the callback was correctly firing after the lib loads.

Thank you!
Yes it's intentional that we load it in more places than are recording events. By design it uses behaviors on those other pages to determine its suspiciousness score.

For context, recaptcha is used on all auth forms -- so we load it on every page because auth can always be launched from the nav bar.

That makes sense to me! I guess I was more wondering about the grecaptcha.execute call that only happens on the homepage. What does that do? (what if someone doesn't visit the homepage)

The homepage is a bit of a special case, we are firing an event that tracks the scores of users on the homepage -- I think this was originally implemented to give us a baseline to consider what scores our users are getting overall. It doesn't do anything except log the score in our dashboard here: https://www.google.com/u/1/recaptcha/admin/site/346113690
Our other events are fired when submitting auth forms, and low scores will trigger a failure to signup from gravity.


Getting 'Page matching query does not exist' error when trying to add a new Page

When trying to add a new Page via wagtailmodeladmin I receive the 'Page matching query does not exist'.
screen shot 2015-08-26 at 15 05 24
screen shot 2015-08-26 at 15 05 45
models.py file
from django.db import models

from wagtail.wagtailcore.models import Page
from wagtail.wagtailcore.fields import RichTextField
from wagtail.wagtailadmin.edit_handlers import FieldPanel
from wagtail.wagtailsnippets.models import register_snippet
from wagtail.wagtailimages.edit_handlers import ImageChooserPanel

class PortfolioPage(Page):
    body = RichTextField(blank=True)
    date = models.DateField("Launch date")
    background = models.ForeignKey(
        'wagtailimages.Image',
        null=True,
        blank=True,
        on_delete=models.SET_NULL,
        related_name='+'
    )

    content_panels = Page.content_panels + [
        FieldPanel('body', classname="full"),
        FieldPanel('date'),
        ImageChooserPanel('background'),
    ]

@register_snippet
class Portfolio(models.Model):
    intro = models.CharField(max_length=255)
    published = models.BooleanField(default=True)

    panels = [
        FieldPanel('published'),
        FieldPanel('intro'),
    ]

    def __str__(self):
        return self.intro

wagtail_hooks.py
from wagtail.wagtailcore import hooks
from wagtailmodeladmin.options import ModelAdmin, ModelAdminGroup, PageModelAdmin
from .models import Portfolio, PortfolioPage

class PortfolioPageAdmin(ModelAdmin):
    model = PortfolioPage
    menu_label = 'Case Study Page' # ditch this to use verbose_name_plural from model
    menu_icon = 'date' # change as required
    menu_order = 200 # will put in 3rd place (000 being 1st, 100 2nd)

class PortfolioAdmin(ModelAdmin):
    model = Portfolio
    menu_label = 'Case Study Snippet' # ditch this to use verbose_name_plural from model
    menu_icon = 'date' # change as required
    menu_order = 100 # will put in 3rd place (000 being 1st, 100 2nd)
    list_display = ('published', 'intro',)
    list_filter = ('published',)
    search_fields = ('intro',)

class PortfolioAdminGroup(ModelAdminGroup):
    menu_label = 'Portfolio'
    menu_icon = 'folder-open-inverse' # change as required
    menu_order = 000 # will put in 3rd place (000 being 1st, 100 2nd)
    items = (PortfolioPageAdmin, PortfolioAdmin)

hook_instance = PortfolioAdminGroup()

@hooks.register('register_permissions')
def register_permissions():
    return hook_instance.get_permissions_for_registration()

@hooks.register('register_admin_urls')
def register_admin_urls():
    return hook_instance.get_admin_urls_for_registration()

@hooks.register('register_admin_menu_item')
def register_admin_menu_item():
    return hook_instance.get_menu_item()

Hi @rosco77! Can I just check whether you have a root page set for your site, and that your pages are children of that page?

Hi @ababic I've actually just destroyed the site I was using and have gone back to vanilla Wagtail so can't fully check.  On my site I had a HomePage that inherited from Page.  This was shown on the Root page of the Wagtail Admin.
The single page you see in the list is the child page that was created under the HomePage using the standard Wagtail Admin.
When I tried to create a page via the wagtailmodeladmin group that's when it gave the error.  I'm not sure how I would configure that to specify it was a child of another page.
Apologies if I'm missing something.  I only started going through Wagtail as a CMS yesterday and the documentation seems to be a bit sparse in places.

@rosco77 I've pushed an update that I'm fairly sure should fix the error you were having. If you have any luck replicating things again in order to test, please let me know :)

Thanks @ababic will test again now and feedback.

It's working now.  Many thanks for the quick fix.  Great app BTW.

No problem. I'm glad you're finding it useful!


Work through list of missing repos tagged as govuk

These missing repos were identified by a new script developed by Platform Reliability, here:
https://github.com/alphagov/govuk-saas-config/pull/142
Some of these repos just need archiving, but others really ought to be represented in the Developer Docs, for visibility of docs and to designate ownership.
I don't intend to merge this as-is, but am using GitHub's PR feature to surface these repos in a forum around which we can decide their fate!
EDIT: also want to add other repos e.g. govuk-app-deployment-private
Trello: https://trello.com/c/tsBL9lPH/2901-work-through-list-of-missing-repos

Have raised #4048, #4049, #4050 and #4051. What's left is a small handful of repos which I'll follow up separately. This PR has served its purpose!


docs

Description
add images to readme file
Screenshots
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[ ] I am willing to work on this issue (optional)
[ ] I am a SWOC'24 contributor

@pinak22dhir Please assign me this issue under IWOC2024

@pinak22dhir Thank you for assigning me with this issue!! To move forward i would like to know from what kind of images specificly you want to be added to your reamde file.

@raysofani clone the repository, and images of project interface, go to different games add its picture

@pinak22dhir kindly close the issue so that i may get points in IWOC2024

@raysofani, in readme ,it is not showing images , please modify it


Add Timeout to http request using ng-http-interceptor

Right now I am adding http timeout individually in all http calls in angular like
this.http.get(baseApiUrl)           .timeoutWith(AppConstants.httpTimeout,Observable.defer(() => Observable.throw(new Error(AppConstants.httpTimeoutMessage))))           .map(Utils.successHandler)           .catch((err) => {             return Utils.errorHandler(err);           });
Is there any way I can make of use ng-http-interceptor , in such a way that I can add timeout to all http calls globally in httpInterceptor.request().addInterceptor method.

Sure, but you need to add timeout in response interceptor since it will have actual http observable:
httpInterceptorService.response().addInterceptor(res =>
  res.timeoutWith(
    AppConstants.httpTimeout,
    Observable.defer(() => Observable.throw(new Error(AppConstants.httpTimeoutMessage))))
      .map(Utils.successHandler)
      .catch((err) => Utils.errorHandler(err)));

Appreciate the solution given.
I tried the above solution. Since the response interceptor gets called only after getting http response. So setting timeout over there doesn't help in my case.  (Since I need to set timeout to http call initially)
Is there anything I am doing wrongly? My full http interceptor code below,
`httpInterceptor.request().addInterceptor((data, method) => {
this.incrementRequestCount();
return data;
});
httpInterceptor.response().addInterceptor((res, method) => {
  res.timeoutWith(
    5000,
    Observable.defer(() => Observable.throw(new Error("Request Timeout"))))

  return res.do((data) => {
    this.decrementRequestCount();
    }, e => {
      console.log(e);
      this.decrementRequestCount();
    });
});`

Timeouts and delays will work just fine as long as you return modified observable.
In your example you setting timeout on observable and do not return it, instead you only returning .do observable.
So just merge both operators in one chain and return that final Observable (because each operator returns new observable and does not mutate original one).

Cool. That works merging both operators and returning final observable.
Really Appreciate that.
Adding final code for a reference to anyone,
`httpInterceptor.response().addInterceptor((res, method) => {
  return res.timeoutWith(
      AppConstants.httpTimeout,
      Observable.defer(() => {
        this.decrementRequestCount();
        return Observable.throw(new Error("Request Timeout"))
      }
    )
  ).do((data) => {
    this.decrementRequestCount();
  });

});`


Support GPS Coordinates

If we're using the browser location or other geo-location  APIs, we will sometimes get only GPS latitude and longitude to work with. It would be really nice if this supported using those coordinates.

I'm not sure if it is that what you are looking for, but please try:
curl wttr.in/-90,0

and compare it with:
curl wttr.in/~South+pole

Here wttr.in/:help you can find all supported input formats.

Aha. That sounds good. I didn't see any documentation that it supported that format. Thank you.

Hello! I cannot get GPS coordinates to work, I always get a 404 Unknown Location error. I've looked at https://wttr.in/:help and as far as I can tell this should work:
curl wttr.in/45.512230,-122.685722?m
However I get the 404 error. I have tried switching the lat and long, tried different locations, tried only 2 numbers after the decimal, but it is the same. Can you help me find out what I'm doing wrong?
Thank you!

"tried only 2 numbers after the decimal, but it is the same."
If I try that with just two decimals, like in the help, it works
curl wttr.in/45.51,-122.68?m gives no 404 error

"tried only 2 numbers after the decimal, but it is the same."
If I try that with just two decimals, like in the help, it works curl wttr.in/45.51,-122.68?m gives no 404 error and "Location: 724, Southwest 3rd Avenue, University District, Downtown, Portland, Multnomah County, Oregon, 97201, USA [45.5100979,-122.6800103]"

Hm, perhaps only some coordinates work? Including two places after the decimal does work for the coordinates above, but another set of coordinates (48.83,-76.54) gives the 404 again:

Can reproduce that 404 here too.
Google maps tells me that these coordinates are in the middle of some Canadian wilderness. Maybe just too fa away from a known station?
But that's just a wild guess, I don't know how the database really works when it comes to coordinates

My bad! I assumed all coordinates would work (or return a closest estimate) and that I was just doing something wrong.
Thank you! I absolutely love this and I'm glad I found it.


Could not introduce k8s.io/kube-openapi@master

How to reproduce?
cd ${GOPATH}/src/github.com/kubeflow
git clone git@github.com:kubeflow/tf-operator.git
dep ensure

Error message
Solving failure: Could not introduce k8s.io/kube-openapi@master, as it requires package k8s.io/klog/v2 from k8s.io/klog, but in version v2.2.0 that package is missing.

I've done with https://github.com/kubeflow/tf-operator/issues/1170, but I can't generate openapi_generated.go
$ ./hack/update-codegen.sh

# output
enerating deepcopy funcs
Generating clientset for tensorflow:v1 at github.com/kubeflow/tf-operator/pkg/client/clientset
Generating listers for tensorflow:v1 at github.com/kubeflow/tf-operator/pkg/client/listers
Generating informers for tensorflow:v1 at github.com/kubeflow/tf-operator/pkg/client/informers
Generating defaulters for tensorflow/v1
Generating OpenAPI specification for tensorflow/v1
./hack/update-codegen.sh: line 45: /home/dslab/go/bin/openapi-gen: No such file or director

Maybe we can use go mod instead soon. Maybe after #1171

@pingsutw
We have already migrated to go mod, you can refer to this PR https://github.com/kubeflow/tf-operator/pull/1144.
So instead of using dep ensure, you have to use go mod download to download the dependencies.
@gaocegege I think we have to update the developer_guide.md to reflect the change

@ChanYiLin Thanks, I will update my PR ASAP.

BTW, for the openapi_generated, you have to install openapi-gen (from https://github.com/kubernetes/kube-openapi) first like defaulter-gen in your {GO_PATH}/bin

/close


File management

Need to be able to interact with a limited subset of the file system.
Specifically, files that are permitted through the outputter as script interaction files.
File managers needed:

[ ] text files
[ ] binary files
[x] yaml files (derive from text files?)
[ ] FDS (FreneticDataSyntax) files.

All set/get for text/yaml should have a distinction between "get_object" and "get_raw" - object includes the object type automatically, raw always treats as plain text!

Should drop yaml in favor of fds

What is fds

@Morphan1 https://github.com/FreneticXYZ/FreneticDataSyntax

What's the point exactly? What does this do that YAML can't handle?

@Morphan1 it's 1000x less random bs code, more stable and trustworthy somehow too.

Less random bs code? Can't you just... Write your own parser for it? I mean that's basically what you seem to be doing anyway, just using a different file extension and possibly removing some features altogether

I'm changing how it functions a bit.


fix x-ms-client-default

fix https://github.com/Azure/autorest.python/issues/1936

thanks for catching this, can you improve the test you added then we should release. thanks! oh also can you add a changelog

done


Move traverse logic to Program exit

I'm apologize for issuing this PR, because it's tailored to the use case
I have of running CommonJS modules in the browser. I've written a
plugin: https://github.com/tbranyen/babel-plugin-transform-commonjs
which converts CommonJS to browser-compatible ESM. I could only think of
two ways to use the two togther: 1) this change (or something similar to
it) is be made, 2) we wait until Babel implements a plugin ordering
system. I believe they are working on the latter.
My CommonJS plugin must run after all other transforms so that dead code
elimination can work properly. What this effectively does is halt the
traversal till the Program exit consistently. This will work reliably
for every plugin that does this, and ensures that all transforms have
run (and may run again) prior to running this plugin.
Thanks in advance!

I'm seeing test failures locally and now seeing them in CI, so I'll work on fixing them.

I'm not sure how I feel about making this change for everyone.  One thought I have is that this plugin could be wrapped:
'use strict';

const basePlugin = require('./index.js');

module.exports = babel => {
  const baseInstance = {...basePlugin(babel)};
  return {
    ...baseInstance,
    visitor: {
      Program: {
        exit(path, state) {
          path.traverse(baseInstance.visitor, state);
        }
      }
    }
  };
};

// Below is optional only if you need this function call.
module.exports.resolve = basePlugin.resolve;

If this script were created as a program-exit.js you could use babel-plugin-bare-import-rewrite/program-exit in your babelrc.  This way you get any bug-fixes that come into this base plugin but without the risk of unintended consequences to other users (you need this plugin to be last, maybe someone else needs it to not be last).  Also it is my understanding that path.traverse adds overhead that could be significant (admittedly I could be mistaken).
As an alternative you could update your fork of to simply extend this plugin as shown above (just alter the require statement to pull my module.  This might not be a bad idea for now anyways, I've already merged a semver-major change but I want to deal with #23 before doing a new release.

Okay, I'll explore a way of making this non-default behavior. There's no huge rush, but this plugin does everything correctly to load a reasonably complex situation so I'd like to get it working with the example app I linked in the issue. While my fork works, I'd like to see unified tooling with Babel, so getting rid of it is a priority for me.


Allow to skip sub tree patching.

I'm trying to use preact as rendering tool for web components custom elements.
I saw the proposal solution on https://github.com/bspaulding/preact-custom-element
But in my case it is not works properly.
First is that I do not using shadow-dom (shadowDOM is imperative and do not allow prerender custom-elements on server side, what I want to achieve).
Second is that I'm trying to mix preact app and preact base custom-elements, or same effect will be when I will nest the preact base custom-elements within preact base custom-elements.
I prepared example https://www.webpackbin.com/bins/-Ki44_xg5yie0o-jHaXv
Problem is that there is no any isolation between the parent render scope (eg root vnodes tree) and nested render scope (eg. some subbranch of vnode tree).
Custom elements should care about render cycle by itself, diff algorithm should never tray to patch the content of custom-elements (even the custom-element will not use the preact). The proposal https://github.com/bspaulding/preact-custom-element toVdom is not solving the problem and is very inefficient.
I tried locally simple patch:
https://github.com/developit/preact/blob/master/src/vdom/diff.js#L128
replaced by:
var isCE = !!window.customElements.get(vnode.nodeName);

if (!isCE) {
    // Optimization: fast-path for elements containing a single TextNode:
    if (!hydrating && vchildren && vchildren.length===1 && typeof vchildren[0]==='string' &&
        fc!=null && fc.splitText!==undefined && fc.nextSibling==null) {
        if (fc.nodeValue!=vchildren[0]) {
            fc.nodeValue = vchildren[0];
        }
    }
    // otherwise, if there are existing or new children, diff them:
    else if (vchildren && vchildren.length || fc!=null) {
        innerDiffNode(out, vchildren, context, mountAll, hydrating ||
            props.dangerouslySetInnerHTML!=null);
    }
}

And after such change everything is works fine.
I know this is not something what preact team will accept :)
But maybe you can add some handler to the options like:
options.skip: (vnode, dom)

and use it:
var skip= options.skip && options.skip(vnode, dom);

if (!skip) {
    // Optimization: fast-path for elements containing a single TextNode:
    if (!hydrating && vchildren && vchildren.length===1 && typeof vchildren[0]==='string' &&
        fc!=null && fc.splitText!==undefined && fc.nextSibling==null) {
        if (fc.nodeValue!=vchildren[0]) {
            fc.nodeValue = vchildren[0];
        }
    }
    // otherwise, if there are existing or new children, diff them:
    else if (vchildren && vchildren.length || fc!=null) {
        innerDiffNode(out, vchildren, context, mountAll, hydrating ||
            props.dangerouslySetInnerHTML!=null);
    }
}

and usage for custom elements:
preact.options.skip = (vnode) => typeof vnode == 'string' && !!window.customElements.get(vnode.nodeName);

Such skip option can be used also as a solution for 'render once' when we know that some sub tree do not have to be never rerendered:
    // preact-one
   function once(vnode) {
        vnode.renderOnce = true;
        return vnode
   }

   preact.options.skip = (vnode, dom) => vnode.renderOnce && dom

and usage
    renderApp() {
         render(

                once(
Static header which will be never rerendered
)

Content rerendered always

, document.body);
    }

The other possibility is to add the property to vnode and instead of condition on options.skip check the property.
if (!vnode.skipChildren) {
    // Optimization: fast-path for elements containing a single TextNode:
    if (!hydrating && vchildren && vchildren.length===1 && typeof vchildren[0]==='string' &&
        fc!=null && fc.splitText!==undefined && fc.nextSibling==null) {
        if (fc.nodeValue!=vchildren[0]) {
            fc.nodeValue = vchildren[0];
        }
    }
    // otherwise, if there are existing or new children, diff them:
    else if (vchildren && vchildren.length || fc!=null) {
        innerDiffNode(out, vchildren, context, mountAll, hydrating ||
            props.dangerouslySetInnerHTML!=null);
    }
}

Then options.vnode can be use to decorate vnode with such options.
As a last word, I can say that many virtual dom implementations provides possibility to 'skip' the subtree patching:
https://github.com/google/incremental-dom/blob/master/test/functional/skip.js
https://github.com/Matt-Esch/virtual-dom/blob/master/docs/thunk.md
...
Best Regards

We have shouldComponentUpdate:false for this, though I admit it's not ideal since it doesn't work for static nodes.  I did find a solution though, posted it on your other issue since it is a modification to preact-custom-element:
https://github.com/bspaulding/preact-custom-element/issues/6#issuecomment-295319646

Thx @developit
(Lets talk in this issue)
Solution is really interesting :)
After last my Issue, I was sure that you will answer in this way :)
Unfortunately proposed solution still is not work as expected.
Please look at https://www.webpackbin.com/bins/-Ki9r5YTAK4A4uxSjIx9
Wrapping to component and close shouldComponentUpdate to false, is also stoping rerender after props/attrs change. I know that I can check the changes in props in shouldComponentUpdate and change the flag to true if there was some changes, but such solution will rerender custom element twice, once rendering of parent will remove children, second rerender of component inside will create nodes again.

Yup yup.  So I can better understand your use-case - are you wanting to keep the Custom Elements in the DOM, or are you always rendering the CE via Preact and it's always implemented via Preact?  In the latter case I have some work lying around that implements CE's within VDOM, might be interesting.

Ok so goal is to support all scenarios :)
Please look at https://github.com/skatejs/skatejs this is small lib based incremental-dom.
In general this lib is a jsx-to-vdom (jsx-to-incremental-dom) + some additional abstraction over web components standard. So it is very similar to what preact/react is but it is focused on custom-elements and it is not supports server side rendering.
I want to do the same, but by using Preact as vdom+jsx-to-vdom, and do not create own new abstraction over the standard.
At the end I was thinking about solution where:

I'm able to write custom elements base on standard api, where preact is used only as a rendering engine. So CE is within own (standard) live cycle calling render(..., this. this.firstChild) by self.
I'm able to create whole application based on custom-elements which are made in this way.

In general I want to be able use Preact only as rendering layer.
But I see that if I will be able to achieve that goals we will be also able to create custom-elements by wrapping preact components.

@majo44 SkateJS 5.0 uses preact instead of incremental-dom.

Wow, so skate going in same direction, but probably because they are always using shadow dom they do not see this problem. (I will try to convince them to add possibility to render also without shadow dom :) This will give a possibility to render skate.js components on server side by domino)

So as I said, in case when skatejs is rendering to light DOM, the problem with patching nested content appears.
https://www.webpackbin.com/bins/-KoOzIcTUxPE7oDkLAWq
Are we able to consider any solution for this problem ?

Wow, so skate going in same direction, but probably because they are always using shadow dom they do not see this problem.

Just for posterity, we allow this now via a custom renderRoot property.

@treshugart Cool, is that already documented somewhere?

@developit
Are we able to consider to add simple vnode check in diff:
if (!vnode.skipChildren) {
    // Optimization: fast-path for elements containing a single TextNode:
    if (!hydrating && vchildren && vchildren.length===1 && typeof vchildren[0]==='string' &&
        fc!=null && fc.splitText!==undefined && fc.nextSibling==null) {
        if (fc.nodeValue!=vchildren[0]) {
            fc.nodeValue = vchildren[0];
        }
    }
    // otherwise, if there are existing or new children, diff them:
    else if (vchildren && vchildren.length || fc!=null) {
        innerDiffNode(out, vchildren, context, mountAll, hydrating ||
            props.dangerouslySetInnerHTML!=null);
    }
}

This change is not a breaking change. I understand this will have some impact on performance but just a little. I was think a lot about other possible solutions but I did not found any better :(
@treshugart
On the skatejs with such change we will be able to use this change by:
let oldVnodeHook = options.vnode;
options.vnode = (vnode) => {
  if (oldVnodeHook) oldVnodeHook(vnode);
  vnode.skipChildren =
    typeof vnode.nodeName === 'string' &&
    vnode.nodeName.indexOf('-') > 0 &&
    isDefined(vnode.nodeName);
};

I even created test in skatejs which is pass after such changes:
define(class extends Component {
      static is = 'x-child';
      get renderRoot () { return this;}
      renderCallback () {
        return 'Child';
      }
    });

    customElements.define('x-parent', class extends Component {
      static props = { 'name': {attribute: true}};
      get renderRoot () { return this;}
      name = 'Foo';
      renderCallback () {
        return vdom('div', {},
          vdom('span', {}, this.name),
          vdom('x-child', {})
        );
      }
    });

    let fix = fixture('<x-parent/>');

    afterMutations(
      () =>  expect(fix.firstChild.firstChild.children[1].innerHTML).toBe('Child'),
      () =>  expect(fix.firstChild.firstChild.children[0].innerHTML).toBe('Foo'),
      () => fix.children[0].name = 'Boo',
      () =>  expect(fix.firstChild.firstChild.children[1].innerHTML).toBe('Child'),
      () =>  expect(fix.firstChild.firstChild.children[0].innerHTML).toBe('Boo'),
      done);

@jmaicher not yet. Will be before final 5.0 release.

FYI: Bailing out of rendering is now supported natively in Preact by returning the same vnode as before. This is best done via memoization via memo, useMemo or a similar approach.