Unnecessary multiple downloads of twin data when setting on_twin_desired_properties_patch_received

Context
Windows 11
Python 3.10.4
Package             Version
------------------- ---------
aiodns              3.0.0
aiohttp             3.8.1
aiosignal           1.2.0
argparse-addons     0.8.0
async-timeout       4.0.2
attrs               21.4.0
azure-iot-device    2.11.0
bincopy             17.10.1
Brotli              1.0.9
cchardet            2.1.7
certifi             2021.10.8
cffi                1.15.0
charset-normalizer  2.0.12
deprecation         2.1.0
frozenlist          1.3.0
grpcio              1.45.0
grpcio-tools        1.45.0
humanfriendly       10.0
idna                3.3
janus               1.0.0
marshmallow         3.15.0
multidict           6.0.2
packaging           21.3
paho-mqtt           1.6.1
pip                 22.0.4
protobuf            3.20.1
pycares             4.1.2
pycparser           2.21
pyelftools          0.28
pyparsing           3.0.8
pyreadline3         3.4.1
PySocks             1.7.1
requests            2.27.1
requests-unixsocket 0.3.0
setuptools          62.1.0
six                 1.16.0
types-protobuf      3.19.18
typing_extensions   4.2.0
urllib3             1.26.9
wheel               0.37.1
yarl                1.7.2

We are using the async client.
Description of the issue
We are on a resource constraint network (very low speed & metered connection), so using as minimal internet as possible is one of our goals making our products. I've noticed that upon setting the on_twin_desired_properties_patch_received handler on the client, when initially connecting it will download 2 copies of the current twin - I would only expect one copy to be downloaded. This adds up quickly when lots of new devices are connected over time.
Without setting the on_twin_desired_properties_patch_received handler we do not get this issue, but also lose out on the automatic twin updates and have to poll instead which is potentially more inefficient in the long term.
Notice in the logs towards the bottom there is:
2022-05-04 20:42:55,035 - paho - DEBUG - Received PUBLISH (d0, q0, r0, m0), '$iothub/twin/res/200/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f', ...  (1429 bytes)
...
2022-05-04 20:42:55,082 - paho - DEBUG - Received PUBLISH (d0, q0, r0, m0), '$iothub/twin/res/200/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f', ...  (1429 bytes)

This is done presumably because of the previous queue up of 2 twin requests after reconnecting:
2022-05-04 20:42:54,972 - azure.iot.device.iothub.pipeline.pipeline_stages_iothub - INFO - {}: Reconnected.  Getting twin
2022-05-04 20:42:54,972 - azure.iot.device.iothub.pipeline.pipeline_stages_iothub - INFO - EnsureDesiredPropertiesStage: sending twin GET to ensure freshness
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(RequestAndResponseOperation): adding request 64fd660a-794b-4f97-89a1-bb07a3d96f9f to pending list
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(RequestAndResponseOperation): Sending twin request to GET resource /
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - RequestOperation: creating worker op of type MQTTPublishOperation
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(MQTTPublishOperation): pipeline is blocked waiting for a prior connect/disconnect/reauthorize to complete.  queueing.
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - PipelineRootStage: ConnectedEvent received. Calling on_connected_handler
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_connected in callback thread
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - INFO - CoordinateRequestAndResponseStage: ConnectedEvent: re-publishing request 64fd660a-794b-4f97-89a1-bb07a3d96f9f for GET twin
2022-05-04 20:42:54,972 - azure.iot.device.iothub.abstract_clients - INFO - Connection State - Connected
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(RequestAndResponseOperation): Sending twin request to GET resource /

Code sample exhibiting the issue
    async def initialise(self) -> None:
        self._main_loop = asyncio.get_running_loop()
        self._logger.info("Initialising IoT hub device client")
        self._client = IoTHubDeviceClient.create_from_connection_string(self._connection_string, auto_connect=False)
        self._logger.info("Initialised IoT hub device client")

        async with self.ensure_connection():
            self._client.on_twin_desired_properties_patch_received = self._handle_twin_desired_properties_patch_received_proxy
            self._logger.debug("Initialised on twin desired properties patch received handler")
            self._client.on_method_request_received = self._handle_method_request_received_proxy
            self._logger.debug("Initialised on method request received handler")
            self._client.on_message_received = self._handle_message_received_proxy
            self._logger.debug("Initialised on message received handler")

        # Bug happens during this stage (this is test code, not our actual code).
        async with self.ensure_connection():
            await asyncio.sleep(3.0)

    @asynccontextmanager
    async def ensure_connection(self) -> None:
        self._logger.debug("Opening IoT hub client connection")
        assert not self._client.connected, "Connection should not be active outside of this context manager"
        await self._client.connect()
        assert self._client.connected
        self._logger.debug("Waiting for connection to settle")
        await asyncio.sleep(1.0)
        self._logger.debug("Opened IoT hub client connection")
        try:
            yield
        finally:
            self._logger.debug("Closing IoT hub client connection")
            assert self._client.connected
            await self._client.disconnect()
            assert not self._client.connected
            self._logger.debug("Closed IoT hub client connection")

Console log of the issue
2022-05-04 20:42:53,137 - gateway3_iot.device_client.device.Field 54115f0080000002 - INFO - Initialising IoT hub device client
2022-05-04 20:42:53,137 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2022-05-04 20:42:53,137 - azure.iot.device.common.pipeline.pipeline_stages_http - DEBUG - Gateway Hostname not present. Setting Hostname to: ...
2022-05-04 20:42:53,137 - azure.iot.device.common.pipeline.pipeline_stages_http - DEBUG - HTTPTransportStage(InitializePipelineOperation): got connection args
2022-05-04 20:42:53,137 - azure.iot.device.common.http_transport - DEBUG - creating a SSL context
2022-05-04 20:42:53,152 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - InitializePipelineOperation: completing without error
2022-05-04 20:42:53,152 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting <azure.iot.device.common.evented_callback.EventedCallback object at 0x000001CEC997D000> in callback thread
2022-05-04 20:42:53,152 - azure.iot.device.common.evented_callback - DEBUG - Callback completed with result None
2022-05-04 20:42:53,152 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2022-05-04 20:42:53,152 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - SasTokenStage: Scheduling automatic SAS Token renewal at epoch time:<PHONE_NUMBER>
2022-05-04 20:42:53,152 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - Gateway Hostname not present. Setting Hostname to: ...
2022-05-04 20:42:53,152 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(InitializePipelineOperation): got connection args
2022-05-04 20:42:53,152 - azure.iot.device.common.mqtt_transport - DEBUG - creating mqtt client
2022-05-04 20:42:53,152 - azure.iot.device.common.mqtt_transport - INFO - Creating client for connecting using MQTT over TCP
2022-05-04 20:42:53,152 - azure.iot.device.common.mqtt_transport - DEBUG - creating a SSL context
2022-05-04 20:42:53,152 - azure.iot.device.common.mqtt_transport - DEBUG - configuring SSL context with default certs
2022-05-04 20:42:53,168 - azure.iot.device.common.mqtt_transport - DEBUG - Created MQTT protocol client, assigned callbacks
2022-05-04 20:42:53,168 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - InitializePipelineOperation: completing without error
2022-05-04 20:42:53,168 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting <azure.iot.device.common.evented_callback.EventedCallback object at 0x000001CEC9981B10> in callback thread
2022-05-04 20:42:53,168 - azure.iot.device.common.evented_callback - DEBUG - Callback completed with result None
2022-05-04 20:42:53,168 - gateway3_iot.device_client.device.Field 54115f0080000002 - INFO - Initialised IoT hub device client
2022-05-04 20:42:53,168 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Opening IoT hub client connection
2022-05-04 20:42:53,168 - azure.iot.device.iothub.aio.async_clients - INFO - Connecting to Hub...
2022-05-04 20:42:53,168 - azure.iot.device.iothub.pipeline.mqtt_pipeline - DEBUG - Starting ConnectOperation on the pipeline
2022-05-04 20:42:53,168 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2022-05-04 20:42:53,168 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ReconnectStage(ConnectOperation): State changes DISCONNECTED -> CONNECTING. Sending op down
2022-05-04 20:42:53,168 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): blocking
2022-05-04 20:42:53,168 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(ConnectOperation): connecting
2022-05-04 20:42:53,168 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(ConnectOperation): Starting watchdog
2022-05-04 20:42:53,168 - azure.iot.device.common.mqtt_transport - DEBUG - connecting to mqtt broker
2022-05-04 20:42:53,168 - azure.iot.device.common.mqtt_transport - INFO - Connect using port 8883 (TCP)
2022-05-04 20:42:53,184 - asyncio - DEBUG - <_ProactorSocketTransport fd=1296> received EOF
2022-05-04 20:42:53,184 - asyncio - DEBUG - <asyncio.sslproto.SSLProtocol object at 0x000001CEC99825F0> received EOF
2022-05-04 20:42:53,497 - paho - DEBUG - Sending CONNECT (u1, p1, wr0, wq0, wf0, c0, k60) client_id=b'54115f0080000002'
2022-05-04 20:42:53,497 - azure.iot.device.common.mqtt_transport - DEBUG - _mqtt_client.connect returned rc=0
2022-05-04 20:42:53,544 - paho - DEBUG - Received CONNACK (1, 0)
2022-05-04 20:42:53,544 - azure.iot.device.common.mqtt_transport - INFO - connected with result code: 0
2022-05-04 20:42:53,544 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_mqtt_connected in pipeline thread
2022-05-04 20:42:53,544 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - INFO - _on_mqtt_connected called
2022-05-04 20:42:53,544 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ReconnectStage(ConnectedEvent): State changes CONNECTING -> CONNECTED. Connection established
2022-05-04 20:42:53,544 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - PipelineRootStage: ConnectedEvent received. Calling on_connected_handler
2022-05-04 20:42:53,544 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_connected in callback thread
2022-05-04 20:42:53,544 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage: completing connect op
2022-05-04 20:42:53,544 - azure.iot.device.iothub.abstract_clients - INFO - Connection State - Connected
2022-05-04 20:42:53,560 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(ConnectOperation): cancelling watchdog
2022-05-04 20:42:53,560 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - ConnectOperation: completing without error
2022-05-04 20:42:53,560 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): op succeeded.  Unblocking queue
2022-05-04 20:42:53,560 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): unblocking and releasing queued ops.
2022-05-04 20:42:53,560 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): processing 0 items in queue for error=None
2022-05-04 20:42:53,560 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in callback thread
2022-05-04 20:42:53,560 - azure.iot.device.common.async_adapter - DEBUG - Callback completed with result None
2022-05-04 20:42:53,560 - azure.iot.device.iothub.aio.async_clients - INFO - Successfully connected to Hub
2022-05-04 20:42:53,560 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Waiting for connection to settle
2022-05-04 20:42:54,564 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Opened IoT hub client connection
2022-05-04 20:42:54,564 - azure.iot.device.iothub.sync_handler_manager - DEBUG - Creating new handler runner for handler: _on_twin_desired_properties_patch_received
2022-05-04 20:42:54,564 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_twin_desired_properties_patch_received): Starting runner
2022-05-04 20:42:54,564 - azure.iot.device.iothub.aio.async_clients - INFO - Enabling feature:twin_patches...
2022-05-04 20:42:54,564 - azure.iot.device.iothub.pipeline.mqtt_pipeline - DEBUG - enable_feature twin_patches called
2022-05-04 20:42:54,564 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2022-05-04 20:42:54,568 - azure.iot.device.iothub.pipeline.pipeline_stages_iothub - DEBUG - EnsureDesiredPropertiesStage: enabling twin patches.  setting last_version_seen
2022-05-04 20:42:54,568 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - EnableFeatureOperation: creating worker op of type MQTTSubscribeOperation
2022-05-04 20:42:54,568 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - OpTimeoutStage(MQTTSubscribeOperation): Creating timer
2022-05-04 20:42:54,568 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - OpTimeoutStage(MQTTSubscribeOperation): Sending down
2022-05-04 20:42:54,568 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTSubscribeOperation): subscribing to $iothub/twin/PATCH/properties/desired/#
2022-05-04 20:42:54,568 - azure.iot.device.common.mqtt_transport - INFO - subscribing to $iothub/twin/PATCH/properties/desired/# with qos 1
2022-05-04 20:42:54,568 - paho - DEBUG - Sending SUBSCRIBE (d0, m1) [(b'$iothub/twin/PATCH/properties/desired/#', 1)]
2022-05-04 20:42:54,568 - azure.iot.device.common.mqtt_transport - DEBUG - _mqtt_client.subscribe returned rc=0
2022-05-04 20:42:54,568 - azure.iot.device.common.mqtt_transport - DEBUG - Waiting for response on MID: 1
2022-05-04 20:42:54,611 - paho - DEBUG - Received SUBACK
2022-05-04 20:42:54,611 - azure.iot.device.common.mqtt_transport - INFO - suback received for 1
2022-05-04 20:42:54,611 - azure.iot.device.common.mqtt_transport - DEBUG - Response received for recognized MID: 1 - triggering callback
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in pipeline thread
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTSubscribeOperation): SUBACK received. completing op.
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - MQTTSubscribeOperation: completing without error
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - OpTimeoutStage(MQTTSubscribeOperation): Cancelling timer
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - EnableFeatureOperation: Worker op (MQTTSubscribeOperation) has been completed
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - EnableFeatureOperation: completing without error
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in callback thread
2022-05-04 20:42:54,611 - azure.iot.device.common.async_adapter - DEBUG - Callback completed with result None
2022-05-04 20:42:54,611 - azure.iot.device.iothub.aio.async_clients - INFO - Successfully enabled feature:twin_patches
2022-05-04 20:42:54,611 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Initialised on twin desired properties patch received handler
2022-05-04 20:42:54,611 - azure.iot.device.iothub.sync_handler_manager - DEBUG - Creating new handler runner for handler: _on_method_request_received
2022-05-04 20:42:54,611 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_method_request_received): Starting runner
2022-05-04 20:42:54,611 - azure.iot.device.iothub.aio.async_clients - INFO - Enabling feature:methods...
2022-05-04 20:42:54,611 - azure.iot.device.iothub.pipeline.mqtt_pipeline - DEBUG - enable_feature methods called
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - EnableFeatureOperation: creating worker op of type MQTTSubscribeOperation
2022-05-04 20:42:54,611 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - OpTimeoutStage(MQTTSubscribeOperation): Creating timer
2022-05-04 20:42:54,627 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - OpTimeoutStage(MQTTSubscribeOperation): Sending down
2022-05-04 20:42:54,627 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTSubscribeOperation): subscribing to $iothub/methods/POST/#
2022-05-04 20:42:54,627 - azure.iot.device.common.mqtt_transport - INFO - subscribing to $iothub/methods/POST/# with qos 1
2022-05-04 20:42:54,627 - paho - DEBUG - Sending SUBSCRIBE (d0, m2) [(b'$iothub/methods/POST/#', 1)]
2022-05-04 20:42:54,627 - azure.iot.device.common.mqtt_transport - DEBUG - _mqtt_client.subscribe returned rc=0
2022-05-04 20:42:54,627 - azure.iot.device.common.mqtt_transport - DEBUG - Waiting for response on MID: 2
2022-05-04 20:42:54,668 - paho - DEBUG - Received SUBACK
2022-05-04 20:42:54,668 - azure.iot.device.common.mqtt_transport - INFO - suback received for 2
2022-05-04 20:42:54,674 - azure.iot.device.common.mqtt_transport - DEBUG - Response received for recognized MID: 2 - triggering callback
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in pipeline thread
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTSubscribeOperation): SUBACK received. completing op.
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - MQTTSubscribeOperation: completing without error
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - OpTimeoutStage(MQTTSubscribeOperation): Cancelling timer
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - EnableFeatureOperation: Worker op (MQTTSubscribeOperation) has been completed
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - EnableFeatureOperation: completing without error
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in callback thread
2022-05-04 20:42:54,674 - azure.iot.device.common.async_adapter - DEBUG - Callback completed with result None
2022-05-04 20:42:54,674 - azure.iot.device.iothub.aio.async_clients - INFO - Successfully enabled feature:methods
2022-05-04 20:42:54,674 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Initialised on method request received handler
2022-05-04 20:42:54,674 - azure.iot.device.iothub.sync_handler_manager - DEBUG - Creating new handler runner for handler: _on_message_received
2022-05-04 20:42:54,674 - azure.iot.device.iothub.aio.async_clients - INFO - Enabling feature:c2d...
2022-05-04 20:42:54,674 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_message_received): Starting runner
2022-05-04 20:42:54,674 - azure.iot.device.iothub.pipeline.mqtt_pipeline - DEBUG - enable_feature c2d called
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - EnableFeatureOperation: creating worker op of type MQTTSubscribeOperation
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - OpTimeoutStage(MQTTSubscribeOperation): Creating timer
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - OpTimeoutStage(MQTTSubscribeOperation): Sending down
2022-05-04 20:42:54,674 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTSubscribeOperation): subscribing to devices/54115f0080000002/messages/devicebound/#
2022-05-04 20:42:54,674 - azure.iot.device.common.mqtt_transport - INFO - subscribing to devices/54115f0080000002/messages/devicebound/# with qos 1
2022-05-04 20:42:54,674 - paho - DEBUG - Sending SUBSCRIBE (d0, m3) [(b'devices/54115f0080000002/messages/devicebound/#', 1)]
2022-05-04 20:42:54,674 - azure.iot.device.common.mqtt_transport - DEBUG - _mqtt_client.subscribe returned rc=0
2022-05-04 20:42:54,674 - azure.iot.device.common.mqtt_transport - DEBUG - Waiting for response on MID: 3
2022-05-04 20:42:54,721 - paho - DEBUG - Received SUBACK
2022-05-04 20:42:54,721 - azure.iot.device.common.mqtt_transport - INFO - suback received for 3
2022-05-04 20:42:54,721 - azure.iot.device.common.mqtt_transport - DEBUG - Response received for recognized MID: 3 - triggering callback
2022-05-04 20:42:54,721 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in pipeline thread
2022-05-04 20:42:54,721 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTSubscribeOperation): SUBACK received. completing op.
2022-05-04 20:42:54,721 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - MQTTSubscribeOperation: completing without error
2022-05-04 20:42:54,721 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - OpTimeoutStage(MQTTSubscribeOperation): Cancelling timer
2022-05-04 20:42:54,721 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - EnableFeatureOperation: Worker op (MQTTSubscribeOperation) has been completed
2022-05-04 20:42:54,721 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - EnableFeatureOperation: completing without error
2022-05-04 20:42:54,721 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in callback thread
2022-05-04 20:42:54,721 - azure.iot.device.common.async_adapter - DEBUG - Callback completed with result None
2022-05-04 20:42:54,721 - azure.iot.device.iothub.aio.async_clients - INFO - Successfully enabled feature:c2d
2022-05-04 20:42:54,721 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Initialised on message received handler
2022-05-04 20:42:54,721 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Closing IoT hub client connection
2022-05-04 20:42:54,721 - azure.iot.device.iothub.aio.async_clients - INFO - Disconnecting from Hub...
2022-05-04 20:42:54,721 - azure.iot.device.iothub.aio.async_clients - DEBUG - Executing initial disconnect
2022-05-04 20:42:54,737 - azure.iot.device.iothub.pipeline.mqtt_pipeline - DEBUG - Starting DisconnectOperation on the pipeline
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ReconnectStage(DisconnectOperation): State changes CONNECTED -> DISCONNECTING. Sending op down.
2022-05-04 20:42:54,737 - asyncio - WARNING - Executing <Task pending name='Task-39' coro=<_handle_exceptions() running at src\python\grpcio\grpc\_cython\_cygrpc/aio/server.pyx.pxi:679> wait_for=<Future pending cb=[_chain_future.<locals>._call_check_cancel() at C:\Program Files\Python310\lib\asyncio\futures.py:384, Task.task_wakeup()] created at C:\Program Files\Python310\lib\asyncio\base_events.py:429> cb=[_add_callback_handler.<locals>.handle_callbacks()] created at C:\Program Files\Python310\lib\asyncio\events.py:80> took 0.172 seconds
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(DisconnectOperation): blocking
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(DisconnectOperation): disconnecting
2022-05-04 20:42:54,737 - azure.iot.device.common.mqtt_transport - INFO - disconnecting MQTT client
2022-05-04 20:42:54,737 - paho - DEBUG - Sending DISCONNECT
2022-05-04 20:42:54,737 - azure.iot.device.common.mqtt_transport - INFO - disconnected with result code: 0
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_mqtt_disconnected in pipeline thread
2022-05-04 20:42:54,737 - azure.iot.device.common.mqtt_transport - DEBUG - _mqtt_client.disconnect returned rc=0
2022-05-04 20:42:54,737 - azure.iot.device.common.mqtt_transport - DEBUG - Cancelling all pending operations
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - INFO - MQTTTransportStage: _on_mqtt_disconnect called
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ReconnectStage(DisconnectedEvent): State changes DISCONNECTING -> DISCONNECTED. Not attempting to reconnect (User-initiated disconnect)
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - PipelineRootStage: DisconnectedEvent received. Calling on_disconnected_handler
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_disconnected in callback thread
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage: Expected disconnect - completing pending disconnect op
2022-05-04 20:42:54,737 - azure.iot.device.iothub.abstract_clients - INFO - Connection State - Disconnected
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - DisconnectOperation: completing without error
2022-05-04 20:42:54,737 - azure.iot.device.iothub.abstract_clients - INFO - Cleared all pending method requests due to disconnect
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(DisconnectOperation): op succeeded.  Unblocking queue
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(DisconnectOperation): unblocking and releasing queued ops.
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(DisconnectOperation): processing 0 items in queue for error=None
2022-05-04 20:42:54,737 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in callback thread
2022-05-04 20:42:54,737 - azure.iot.device.common.async_adapter - DEBUG - Callback completed with result None
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_clients - DEBUG - Successfully executed initial disconnect
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_clients - DEBUG - Stopping handlers...
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - Adding HandlerRunnerKillerSentinel to inbox corresponding to _on_message_received handler runner
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - Waiting for _on_message_received handler runner to exit...
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_message_received): HandlerRunnerKillerSentinel found in inbox. Exiting.
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_message_received): Task successfully completed without exception
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - Handler runner for _on_message_received has been stopped
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - Adding HandlerRunnerKillerSentinel to inbox corresponding to _on_method_request_received handler runner
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - Waiting for _on_method_request_received handler runner to exit...
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_method_request_received): HandlerRunnerKillerSentinel found in inbox. Exiting.
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_method_request_received): Task successfully completed without exception
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - Handler runner for _on_method_request_received has been stopped
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - Adding HandlerRunnerKillerSentinel to inbox corresponding to _on_twin_desired_properties_patch_received handler runner
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - Waiting for _on_twin_desired_properties_patch_received handler runner to exit...
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_twin_desired_properties_patch_received): HandlerRunnerKillerSentinel found in inbox. Exiting.
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_twin_desired_properties_patch_received): Task successfully completed without exception
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - Handler runner for _on_twin_desired_properties_patch_received has been stopped
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_clients - DEBUG - Successfully stopped handlers
2022-05-04 20:42:54,752 - azure.iot.device.iothub.aio.async_clients - DEBUG - Executing secondary disconnect...
2022-05-04 20:42:54,752 - azure.iot.device.iothub.pipeline.mqtt_pipeline - DEBUG - Starting DisconnectOperation on the pipeline
2022-05-04 20:42:54,752 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2022-05-04 20:42:54,752 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ReconnectStage(DisconnectOperation): State is already DISCONNECTED. Sending op down
2022-05-04 20:42:54,752 - azure.iot.device.common.pipeline.pipeline_stages_base - INFO - ConnectionLockStage(DisconnectOperation): Transport is already disconnected.  Completing.
2022-05-04 20:42:54,752 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - DisconnectOperation: completing without error
2022-05-04 20:42:54,752 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in callback thread
2022-05-04 20:42:54,752 - azure.iot.device.common.async_adapter - DEBUG - Callback completed with result None
2022-05-04 20:42:54,769 - azure.iot.device.iothub.aio.async_clients - DEBUG - Successfully executed secondary disconnect
2022-05-04 20:42:54,769 - azure.iot.device.iothub.aio.async_clients - INFO - Successfully disconnected from Hub
2022-05-04 20:42:54,769 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Closed IoT hub client connection
2022-05-04 20:42:54,769 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Opening IoT hub client connection
2022-05-04 20:42:54,769 - azure.iot.device.iothub.aio.async_clients - INFO - Connecting to Hub...
2022-05-04 20:42:54,769 - azure.iot.device.iothub.pipeline.mqtt_pipeline - DEBUG - Starting ConnectOperation on the pipeline
2022-05-04 20:42:54,769 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting run_op in pipeline thread
2022-05-04 20:42:54,769 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ReconnectStage(ConnectOperation): State changes DISCONNECTED -> CONNECTING. Sending op down
2022-05-04 20:42:54,769 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): blocking
2022-05-04 20:42:54,769 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(ConnectOperation): connecting
2022-05-04 20:42:54,769 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(ConnectOperation): Starting watchdog
2022-05-04 20:42:54,769 - azure.iot.device.common.mqtt_transport - DEBUG - connecting to mqtt broker
2022-05-04 20:42:54,769 - azure.iot.device.common.mqtt_transport - INFO - Connect using port 8883 (TCP)
2022-05-04 20:42:54,909 - paho - DEBUG - Sending CONNECT (u1, p1, wr0, wq0, wf0, c0, k60) client_id=b'54115f0080000002'
2022-05-04 20:42:54,909 - azure.iot.device.common.mqtt_transport - DEBUG - _mqtt_client.connect returned rc=0
2022-05-04 20:42:54,972 - paho - DEBUG - Received CONNACK (1, 0)
2022-05-04 20:42:54,972 - azure.iot.device.common.mqtt_transport - INFO - connected with result code: 0
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_mqtt_connected in pipeline thread
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - INFO - _on_mqtt_connected called
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ReconnectStage(ConnectedEvent): State changes CONNECTING -> CONNECTED. Connection established
2022-05-04 20:42:54,972 - azure.iot.device.iothub.pipeline.pipeline_stages_iothub - INFO - {}: Reconnected.  Getting twin
2022-05-04 20:42:54,972 - azure.iot.device.iothub.pipeline.pipeline_stages_iothub - INFO - EnsureDesiredPropertiesStage: sending twin GET to ensure freshness
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(RequestAndResponseOperation): adding request 64fd660a-794b-4f97-89a1-bb07a3d96f9f to pending list
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(RequestAndResponseOperation): Sending twin request to GET resource /
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - RequestOperation: creating worker op of type MQTTPublishOperation
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(MQTTPublishOperation): pipeline is blocked waiting for a prior connect/disconnect/reauthorize to complete.  queueing.
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - PipelineRootStage: ConnectedEvent received. Calling on_connected_handler
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_connected in callback thread
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - INFO - CoordinateRequestAndResponseStage: ConnectedEvent: re-publishing request 64fd660a-794b-4f97-89a1-bb07a3d96f9f for GET twin
2022-05-04 20:42:54,972 - azure.iot.device.iothub.abstract_clients - INFO - Connection State - Connected
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(RequestAndResponseOperation): Sending twin request to GET resource /
2022-05-04 20:42:54,972 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_message_received): Starting runner
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - RequestOperation: creating worker op of type MQTTPublishOperation
2022-05-04 20:42:54,972 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_method_request_received): Starting runner
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(MQTTPublishOperation): pipeline is blocked waiting for a prior connect/disconnect/reauthorize to complete.  queueing.
2022-05-04 20:42:54,972 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_twin_desired_properties_patch_received): Starting runner
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage: completing connect op
2022-05-04 20:42:54,972 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(ConnectOperation): cancelling watchdog
2022-05-04 20:42:54,988 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - ConnectOperation: completing without error
2022-05-04 20:42:54,988 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): op succeeded.  Unblocking queue
2022-05-04 20:42:54,988 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): unblocking and releasing queued ops.
2022-05-04 20:42:54,988 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): processing 2 items in queue for error=None
2022-05-04 20:42:54,988 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): releasing MQTTPublishOperation op.
2022-05-04 20:42:54,988 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTPublishOperation): publishing on $iothub/twin/GET/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:54,988 - azure.iot.device.common.mqtt_transport - INFO - publishing on $iothub/twin/GET/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:54,988 - paho - DEBUG - Sending PUBLISH (d0, q1, r0, m4), 'b'$iothub/twin/GET/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f'', ... (1 bytes)
2022-05-04 20:42:54,988 - azure.iot.device.common.mqtt_transport - DEBUG - _mqtt_client.publish returned rc=0
2022-05-04 20:42:54,988 - azure.iot.device.common.mqtt_transport - DEBUG - Waiting for response on MID: 4
2022-05-04 20:42:54,988 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - ConnectionLockStage(ConnectOperation): releasing MQTTPublishOperation op.
2022-05-04 20:42:54,988 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTPublishOperation): publishing on $iothub/twin/GET/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:54,988 - azure.iot.device.common.mqtt_transport - INFO - publishing on $iothub/twin/GET/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:54,988 - paho - DEBUG - Sending PUBLISH (d0, q1, r0, m5), 'b'$iothub/twin/GET/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f'', ... (1 bytes)
2022-05-04 20:42:54,988 - azure.iot.device.common.mqtt_transport - DEBUG - _mqtt_client.publish returned rc=0
2022-05-04 20:42:54,988 - azure.iot.device.common.mqtt_transport - DEBUG - Waiting for response on MID: 5
2022-05-04 20:42:54,988 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in callback thread
2022-05-04 20:42:54,988 - azure.iot.device.common.async_adapter - DEBUG - Callback completed with result None
2022-05-04 20:42:54,988 - azure.iot.device.iothub.aio.async_clients - INFO - Successfully connected to Hub
2022-05-04 20:42:54,988 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Waiting for connection to settle
2022-05-04 20:42:55,035 - paho - DEBUG - Received PUBACK (Mid: 4)
2022-05-04 20:42:55,035 - azure.iot.device.common.mqtt_transport - INFO - payload published for 4
2022-05-04 20:42:55,035 - azure.iot.device.common.mqtt_transport - DEBUG - Response received for recognized MID: 4 - triggering callback
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in pipeline thread
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTPublishOperation): PUBACK received. completing op.
2022-05-04 20:42:55,035 - paho - DEBUG - Received PUBLISH (d0, q0, r0, m0), '$iothub/twin/res/200/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f', ...  (1429 bytes)
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - MQTTPublishOperation: completing without error
2022-05-04 20:42:55,035 - azure.iot.device.common.mqtt_transport - INFO - message received on $iothub/twin/res/200/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - RequestOperation: Worker op (MQTTPublishOperation) has been completed
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_mqtt_message_received in pipeline thread
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - RequestOperation: completing without error
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(RequestAndResponseOperation): Finished sending twin request to GET resource /
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage: message received on topic $iothub/twin/res/200/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(ResponseEvent): Handling event with request_id 64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(RequestAndResponseOperation): Completing twin request to GET resource / with status 200
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - RequestAndResponseOperation: completing without error
2022-05-04 20:42:55,035 - azure.iot.device.iothub.pipeline.pipeline_stages_iothub - DEBUG - TwinRequestResponseStage(RequestAndResponseOperation): Got response for GetTwinOperation
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - GetTwinOperation: completing without error
2022-05-04 20:42:55,035 - azure.iot.device.iothub.pipeline.pipeline_stages_iothub - DEBUG - <azure.iot.device.iothub.pipeline.pipeline_stages_iothub.EnsureDesiredPropertiesStage object at 0x000001CEC9981AB0> Twin GET response received.  Checking versions
2022-05-04 20:42:55,035 - azure.iot.device.iothub.pipeline.pipeline_stages_iothub - DEBUG - EnsureDesiredPropertiesStage: old version = -1, new version = 1
2022-05-04 20:42:55,035 - azure.iot.device.iothub.pipeline.pipeline_stages_iothub - DEBUG - EnsureDesiredPropertiesStage: Version changed.  Sending up new patch event
2022-05-04 20:42:55,035 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_pipeline_event in callback thread
2022-05-04 20:42:55,035 - azure.iot.device.iothub.inbox_manager - DEBUG - twin patch message sent to inbox
2022-05-04 20:42:55,035 - azure.iot.device.iothub.aio.async_handler_manager - DEBUG - HANDLER RUNNER (_on_twin_desired_properties_patch_received): Invoking handler
2022-05-04 20:42:55,035 - azure.iot.device.iothub.aio.loop_management - DEBUG - Creating new event loop - CLIENT_HANDLER_LOOP
2022-05-04 20:42:55,035 - asyncio - DEBUG - Using proactor: IocpProactor
2022-05-04 20:42:55,050 - azure.iot.device.iothub.sync_handler_manager - DEBUG - HANDLER (CLIENT_EVENT): Successfully completed invocation
2022-05-04 20:42:55,050 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Twin Desired Properties Patch Received callback invoked
... (uses twin event) ...
2022-05-04 20:42:55,069 - paho - DEBUG - Received PUBACK (Mid: 5)
2022-05-04 20:42:55,082 - azure.iot.device.common.mqtt_transport - INFO - payload published for 5
2022-05-04 20:42:55,082 - azure.iot.device.common.mqtt_transport - DEBUG - Response received for recognized MID: 5 - triggering callback
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting on_complete in pipeline thread
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage(MQTTPublishOperation): PUBACK received. completing op.
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - MQTTPublishOperation: completing without error
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - RequestOperation: Worker op (MQTTPublishOperation) has been completed
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_ops_base - DEBUG - RequestOperation: completing without error
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(RequestAndResponseOperation): Finished sending twin request to GET resource /
2022-05-04 20:42:55,082 - paho - DEBUG - Received PUBLISH (d0, q0, r0, m0), '$iothub/twin/res/200/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f', ...  (1429 bytes)
2022-05-04 20:42:55,082 - azure.iot.device.common.mqtt_transport - INFO - message received on $iothub/twin/res/200/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_thread - DEBUG - Starting _on_mqtt_message_received in pipeline thread
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_stages_mqtt - DEBUG - MQTTTransportStage: message received on topic $iothub/twin/res/200/?$rid=64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_stages_base - DEBUG - CoordinateRequestAndResponseStage(ResponseEvent): Handling event with request_id 64fd660a-794b-4f97-89a1-bb07a3d96f9f
2022-05-04 20:42:55,082 - azure.iot.device.common.pipeline.pipeline_stages_base - INFO - CoordinateRequestAndResponseStage(ResponseEvent): request_id 64fd660a-794b-4f97-89a1-bb07a3d96f9f not found in pending list.  Nothing to do.  Dropping
2022-05-04 20:42:55,976 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Opened IoT hub client connection
2022-05-04 20:42:58,990 - gateway3_iot.device_client.device.Field 54115f0080000002 - DEBUG - Closing IoT hub client connection

We have successfully been able to reproduce this issue, and are now working on a fix. Thank you very much for the sample code - it helped a lot.
To be clear, one full twin retrieval is the expected behavior upon re-establishing a connection. However, it happening twice is incorrect, and that is the aspect we will be fixing.


v2.1.1 no longer seems to ignore_folders

Again in the process of attempting to update mkdocs_semiliterate, this time to v2.1.1 (which is OK with a single extract block, thanks), I am finding that if I for example have 'tests' in my ignore_folders parameter, files in my tests/ directory are still being scanned. The change seems to be that in prior code, the file tree was walked in Simple.build_docs and the loop included the line:
                directories[:] = [
                    d for d in directories if not self.is_ignored(root, d)]

but now the file tree is walked in Simple.get_files and the apparently corresponding loop has no filter on directories. Please let me know how I can assist with this situation.

It should filter directories.
ref
        # Check for ignore folder in patterns
        if any(fnmatch.fnmatch(base_path, filter)
                for filter in self.ignore_glob):
            return True

You need to use a glob pattern that will work from the base directory.

Well, I have a top-level directory named tests and I have the string tests as one of the entries in ignore_folders, and yet tests/fixtures/extract-inclusion/README.md is being scanned, which it was not before. tests surely matches tests, so I believe I am specifying that the top-level tests folder should be ignored, and yet it seems to be walked... Should I provide a complete example of such a project tree? If so, what's the most convenient way for you?

Ah, I see the issue.
I'll throw up a fix.

I could be wrong but it seems to me that the new test you wrote never creates a goo/night.md file and so isn't really testing that such a file is ignored... just thought I'd mention.

bah.  Thanks!


*: Cut v2.29.0-rc.1

@roidelapluie @SuperQ @codesome @juliusv

Could we have #9119 as well?

Added

LGTM


add redirect from http to https in nginx configuration

... but only for server deployments

Updated Files
https://github.com/WHOIGit/photic/pull/224/files


⚠ Bofrost.be has degraded performance

In 3913bd3, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1851 ms

Resolved: Bofrost.be performance has improved in 7a3b29d after 10 minutes.


Add PH events to when we show ANY of the new idle notifications

@doppleware
There are events already
These are the events
Notifications.Show.DigmaHasntBeenRunningForAWhile
Notifications.Show.DigmaHasntBeenOpenedForAWhile
Notifications.Show.DigmaHasntBeenActivated
'ShowTypeform link clicked'
details: origin=DigmaHasntBeenRunningForAWhile
'ShowTypeform link clicked'
details: origin=DigmaHasntBeenOpenedForAWhile
'ShowTypeform link clicked'
details: origin=DigmaHasntBeenActivated
'GoAway link clicked'
details: origin=DigmaHasntBeenRunningForAWhile
'GoAway link clicked'
details: origin=DigmaHasntBeenOpenedForAWhile
'GoAway link clicked'
details: origin=DigmaHasntBeenActivated
Notifications.DigmaHasntBeenRunningForAWhile.clicked
Notifications.DigmaHasntBeenOpenedForAWhile.clicked
Notifications.DigmaHasntBeenActivated.clicked
you should see something like that
GoAway link clicked
Notifications.DigmaHasntBeenOpenedForAWhile.clicked
Notifications.Show.DigmaHasntBeenOpenedForAWhile
or
ShowTypeform link clicked
Notifications.DigmaHasntBeenRunningForAWhile.clicked
Notifications.Show.DigmaHasntBeenRunningForAWhile


Curve_fit bounds and maxfev

It is not possible to specify both bounds and the maxfev parameter to curve fit in scipy 0.17.1:
import numpy as np
from scipy.optimize import curve_fit

x = np.arange(0,10)
y = 2*x
curve_fit(lambda x,p: p*x, x, y, maxfev=100)
curve_fit(lambda x,p: p*x, x, y, bounds=(0,3), maxfev=100)

Error:
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-9-e43f99ae5657> in <module>()
      2 y = 2*x
      3 curve_fit(lambda x,p: p*x, x, y, maxfev=100)
----> 4 curve_fit(lambda x,p: p*x, x, y, bounds=(0,3), maxfev=100)

C:\Users\xxx\AppData\Local\Continuum\Anaconda3\envs\py27\lib\site-packages\scipy\optimize\minpack.pyc in curve_fit(f, xdata, ydata, p0, sigma, absolute_sigma, check_finite, bounds, method, **kwargs)
    656     else:
    657         res = least_squares(func, p0, args=args, bounds=bounds, method=method,
--> 658                             **kwargs)
    659
    660         if not res.success:

TypeError: least_squares() got an unexpected keyword argument 'maxfev'

When bounds are specified, curve_fit delegates to least_squares, http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.least_squares.html
And name of the parameter is max_nfev:
In [8]: curve_fit(lambda x, a: a*x, x, 2*x, bounds=(0, 3), max_nfev=30)
Out[8]: (array([ 2.]), array([[  3.64244449e-32]]))

So yeah, it's a bit inconsistent.

@vascotenner https://github.com/scipy/scipy/pull/6341

I was having the same issue. This is a great help.

This is a great help. I was having the same issue.

Just what I was looking for

mark


Provide RU Translation

I was guided by the terms of the official russian translation from the publisher "Стиль Жизни"

thanks for the contribution! - released as v1.0.6


osVersion is null

Hello,
I recently uncovered an interesting issue while developing with this library. I am developing in Arch Linux (using Firefox 68) and will occasionally get the following error:
Unhandled promise rejection TypeError: "osVersion is null"
I tracked down the offending block of code and it looks like this is being thrown in the detectDesktopOS function. This only happens when I use Firefox's Responsive Design Mode and emulate an Apple device (iPad, iPhone, etc) so it seems like this function throws an error (causing the constructor to fail) when it doesn't expect a particular combination of OS version and user-agent string.
Reading through the source, it looks like that function is based on this particular jsfiddle. I can reproduce the exact error using the fiddle, so it seems like the original code didn't account for this particular (albeit extremely rare) edge case.
My fix was to set the Responsive Design Mode device to 'Responsive' (which doesn't change the user-agent string). Just wanted to share my findings to save someone else some headache.
Thanks for all your hard work!

@slaponicus  Thank You, this saved my day !! 😃  👍


hakai_salmon_data: occurrence file

The occurrence file seems to have extraneous information from the WoRMS lookup included that don't align to Darwin Core terms (eg isMarine, isBrackish, Qualitystatus, TSN, Citation, etc). I would recommend removing these from the occurrence file unless you have a reason to keep them in.

Are these things that should go in the MoF associated with the occurence?
isMarine, isBrackish, Citation might be superfluous but maybe Qualitystatus would be useful?
I guess I don't really know the meaning of the terms used.

No these are not facts about the occurrence. They are facts about the taxonomic assessment. So these are not pieces of information that are being collected in the field or a lab. Instead it's information coming back from the WoRMS API using taxize about the taxonomic assessment of the species as a whole. I don't think it makes sense to duplicate this information in our OBIS data since it's already available and retrievable in WoRMS if you need it. What we don't want to lose are measurements or facts that are collected with the event/occurrence and will be lost if we don't share it using Darwin Core.

Got it. Thanks Abby!
On Wed, Nov 13, 2019 at 5:46 PM Abby Benson<EMAIL_ADDRESS>wrote:

No these are not facts about the occurrence. They are facts about the
taxonomic assessment. So these are not pieces of information that are being
collected in the field or a lab. Instead it's information coming back from
the WoRMS API using taxize about the taxonomic assessment of the species as
a whole. I don't think it makes sense to duplicate this information in our
OBIS data since it's already available and retrievable in WoRMS if you need
it. What we don't want to lose are measurements or facts that are collected
with the event/occurrence and will be lost if we don't share it using
Darwin Core.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/marinebon/ioos_bio_data_scripts/issues/7?email_source=notifications&email_token=AAIAV7QA37A74UYLQI5QKZLQTR7T3A5CNFSM4JIANY5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED754GQ#issuecomment-553639450,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIAV7U2Z7TCG77FH5AMEEDQTR7T3ANCNFSM4JIANY5A
.

--
===========================================
Tylar Murray http://tylar.info, Ph.D.
IMaRS http://imars.marine.usf.edu/ Research Systems & Software Engineer
USF CMS http://marine.usf.edu - KRC 3119-B
------------------------------------------
schedule : g-calendar
https://calendar.google.com/calendar?cid=NWRuOHRubTBmczlmZjN0cTVhMGczbnBqbXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ,
youcanbookme https://7yl4r.youcanbook.me/
===========================================


Review

@justTOBBI
Excellent work, these themes look really good! Here are a couple of suggestions. If you make changes, don't forget to re-upload! Are you on the RemNote Discord? Let me know your Discord ID and I'll give you the extension-developer role :)

Small bug when the UI fades after typing in a document:

https://github.com/catppuccin/remnote/blob/0296af8ae56e75fd8934469fb96ba884769f0fa4/frappé/theme.css#L74-L76
You can change this line in each theme to var(--base)!important to fix this.

Consider making the themes available on mobile if they work.

https://github.com/catppuccin/remnote/blob/0296af8ae56e75fd8934469fb96ba884769f0fa4/frappé/manifest.json#L7

Consider adding a logo.png to the zip file. It will get displayed here:

Hey,
the feedback is very much appreciated and if @coldenate isn't against it, I would tackle these Issues in the next couple days.
Thank you very much for taking a look at this :D

Yes! For sure! @bjsi I am happy to also tackle these issues soon.
Thank you for offering, our ids are<PHONE_NUMBER>38531595,<PHONE_NUMBER>86610433.
Most of the packaging was done locally, so I may try and tinker with some automation. For now, I'll stick to traditional methods :).

Consider making the themes available on mobile if they work.

I will further look into this, but I think that was my mistake labeling it as incompatible with mobile! Currently, all the bugs discovered have parity across device types. Thank you for pointing the manifest file out! 😅 @bjsi

Hey, I just pushed the changes pointed out in your commit.
@coldenate, it would be awesome if you could add the logo to the marketplace, since I really dont know how to do that lmao

Sure! I will get that done. On my branch, the suggested !important change seemed to not fix the issue. Did it work in your instance? @justTOBBI

I can double confirm that the change doesn't fix what I presume as the "Zen Mode". I am planning on reworking the whole repo to align with the successful themes already on the market.

So yeh, I didnt really test it out, since my Remnote was slow af when I tried to remove the old CSS and added the new, so I just added the change bjsi suggested.

I'm starting to notice a trend with many other themes on the marketplace also having this issue. I'm going to ask around on the Discord tomorrow, and I'll see if I need to open a support ticket.

@bjsi Have you heard of this issue with Zen Mode from anyone before?

Rightyo! I fixed up the issues with many thanks to @akirathesquid, and I pushed them to a pr.

Hi @bjsi, I have a question about how the theming works 😅  ...
Will I be able to bundle the palette_values.css and import them from theme.css even though theme.css contains the actual theme assignments?
does it have to be monofile?


Feature request: Advanced exporting with tags

Would be nice to specify tags are in "OR" or "AND" mode. Currently when exporting with multiple tags all the translations with "any" of tags are exported. I would like to export translation where "all" mentioned tags present.

How about +/- prefixes to specify how a tag condition should be used?
--tags tag1,tag2,tag3 -> (tag1 OR tag2 OR tag3)    # current behavior
--tags +tag1,+tag2,+tag3 -> (tag1 AND tag2 AND tag3)
--tags -tag1,-tag2,-tag3 -> !(tag1 OR tag2 OR tag3)
--tags tag1,tag2,+tag3 -> (tag1 OR tag2) AND (tag3)
--tags tag1,tag2,+tag3,+tag4 -> (tag1 OR tag2) AND (tag3 AND tag4)
--tags tag1,tag2,-tag3 -> (tag1 OR tag2) AND !(tag3)
--tags tag1,tag2,-tag3,-tag4 -> (tag1 OR tag2) AND !(tag3 OR tag4)
--tags tag1,tag2,+tag3,+tag4,-tag5,tag6 -> (tag1 OR tag2) AND (tag3 AND tag4) AND !(tag3 OR tag4)

This would also solve #98.
@scelis, opinions?

Are there other tools that do similar ORing and ANDing (and maybe NOTing)? I find the order of operations above (without explicit parentheses) quite hard to follow.

My command-line-foo is pretty weak and I actually don't know very many CLIs, so not that I'm aware of :-) Maybe the rules seem more complicated than what I had in mind.

Group all tags without prefix and OR them
Group all tags with + and AND them
Group all tags with - and OR them - invert this group (!)
Join all Groups with AND

So the last example could be reordered and still yield the same result:
--tags -tag6,tag2,+tag3,tag1,+tag4,-tag5 -> (tag1 OR tag2) AND (tag3 AND tag4) AND !(tag5 OR tag6)

And maybe the rules become even simpler if the third one is rephrased: Invert all tags with - and AND them. The result would be
--tags tag1,tag2,+tag3,+tag4,-tag5,-tag6 -> (tag1 OR tag2) AND (tag3 AND tag4) AND (!tag5 AND !tag6)

@dmi3j, @rk13: you requested this feature, what's your opinion?

My initial idea was instead of currently available:
--tags tag1,tag2,tag3
which basically means OR to have
--anytags tags1,tags2,tag3 = OR
and
--alltags tag1,tag2,tag3 = AND
It's hard to image who would needs comprehensive combinations of OR and AND

For #98 we'd also need --notags tag1,tag2,tag3 or something like that. Would those command line arguments be combinable then, too?

@scelis, what do you like better? A little more complex syntax or more command line options?
I personally prefer the syntax, because

we wouldn't get rid of the "how do all these combine" complexity by separating the options
it's even harder to understand if the tags aren't listed together
twine already has a ton of command line options ;-)
if this is an advanced feature, it's okay if it's not 100% obvious and needs a quick readme lookup

Honestly, both of these options seem overly complicated to me. What about a separator other than comma for ANDing?
--tags a+b+c+d
Comma for OR, plus for AND. If there are both, ORs have a higher order of precedence. ! Could be added for NOT if necessary or that could be done in a later PR.

So --tags a+b,c+d would be a AND (b or c) AND d?
Since filtering for missing tags is already on the list, I'd like to at least come up with a plan on how it would work to be sure it will work.
--tags a,b+c+d!e!f -> (a OR b) AND c AND d AND !e AND !f?
I'm cool with that :-)

The not still requires an OR or AND separator.
--tags a,b+c,!d+!f

Cucumber project has quite simple logical ANDing and ORing for tags
https://github.com/cucumber/cucumber/wiki/Tags
Scenarios which match @important OR @billing
cucumber --tags @billing,@important
Running scenarios which match @important AND @billing
cucumber --tags @billing --tags @important
Applying similar approach for Twine might result
OR (currently available)
--tags tag1,tag2
AND
--tags tags1 --tags tags2

I need to check how the OptionParser handles arguments that are specified multiple times.

It's supported, so we could also do that. --tags a,b+c,!d+!f would then be --tags a,b --tags c,~d --tags ~f. @scelis, which one shall it be? ;-)

Hmm, I'd like to see if we can find 1 or 2 more tools that do something similar before deciding.

All right, here we go:
Cucumber
AND := --tags @billing --tags @important
OR := --tags @billing,@important
NOT := n/a
Source
Rspec
AND := --tag billing --tag important
OR := n/a
NOT := --tag ~billing
Source
Explanation
behat
AND := --tags billing&&important
OR := --tags billing,important
NOT := --tags ~billing
Source
AWS EC2
AND := --filters "Name=tag:Name,Values=xxx" "Name=tag:env,Values=dev"
OR := --filter tag:Purpose=X --filter tag:Purpose=Y
NOT := n/a
Source
Explanation
I also looked at Android's logcat, but that doesn't really apply.
Results

We should keep the rule that --tags billing,important means OR to not break the existing interface.
It's common to supply the same argument multiple times, for us that concatenation would be AND (because , is OR)
It's common to use ~ as negation

Awesome! Thanks so much for looking into this. I agree totally with your assessments.


Dispatch 'bolt:layout-size-changed' after MicroJourney change page he…

Added dispatch 'bolt:layout-size-changed' event after pathway is loaded or changed.
Jira
WWWD-4784
Summary
Microjourney component height interacts with offsets calculated by nav-indicator. They must be updated after pathway changed.

PR was released with v2.24.0


Refactored motion physics and added force method

Codecov Report

Merging #91 into master will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #91      +/-   ##
==========================================
- Coverage   98.30%   98.30%   -0.01%
==========================================
  Files           9        9
  Lines         532      531       -1
==========================================
- Hits          523      522       -1
  Misses          9        9

Impacted Files
Coverage Δ

core/dimensions.py
94.59% <100.00%> (+0.30%)
:arrow_up:

physics/motion.py
98.24% <100.00%> (-0.15%)
:arrow_down:

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 f35448d...710d25b. Read the comment docs.


Discontinuities in the Pose Graph

🐛 Describe the bug
I use pose graph implementation and optimization from the examples.
When optimizing my own pose graph with an identity information matrix for the neighboring nodes, the resulting graph can have discontinuities. Under discontinuity, I mean really strong jumps between consecutive nodes in the graph.
On the attached picture you can see the ground-truth graph (GT), estimated graph, and a graph optimized with pypose. There's a huge jump at the very bottom of the image (6 dots)

When running PGO with G2O, there are no discontinuities like that.
I also checked that optimizers used in both G2O and pypose are the same.
Do you know any possible reason for such behavior?
Versions
Pypose version: 0.4.4

Hi, it would be great if you could provide your scripts and data so that we can reproduce your results. I am guessing that some hyperparameter tuning may be able to solve this problem.

Thanks for your response. Will provide the repro scripts + data soon.
Another question on that note, How can I freeze some nodes during optimization? For example, nodes A and B are connected by an edge, but I know that node A is a ground-truth and I don't want to change it. However, I'm still interested in changing B based on the constraint between A and B.

Hi, given the use case, you have multiple options.
(1) You only need to define model.B as pp.Parameter and define model.A as normal torch.Tensor or pp.LieTensor.
(2) Only provide model.B to optimizers, e.g., optim = pp.optim.LM(model.B, ...) or optim = torch.optim.SGD(model.B.parameters(), ...).

For the 1) option, it is still a little bit unclear. My forward function looks like this:
    def forward(self, edges, poses):
        node1 = self.nodes[edges[..., 0]]
        node2 = self.nodes[edges[..., 1]]
        error = poses.Inv() @ node1.Inv() @ node2
        return error.Log().tensor()

Now if I want to make a node with id = i static. It also has an edge over another node with id = j which I want to optimize based on that edge.
Now self.nodes = pp.Parameter(pp.SE3(cur_nodes.float())). How can I make the node at index i static in that case?

Hi. How many static nodes do you have?

If only one (e.g. a common demand is to fix the first node), you can consider first solve the PGO, then transform the whole graph back (calculate the displacement of the static node caused by PGO, and transform all nodes use the inverse of this transformation).
If more than one, I'd recommend using two tensors, one for static nodes (model.B) and the other for the nodes to be optimized (model.A). Then you can follow the previous answer:

Hi, given the use case, you have multiple options. (1) You only need to define model.B as pp.Parameter and define model.A as normal torch.Tensor or pp.LieTensor. (2) Only provide model.B to optimizers, e.g., optim = pp.optim.LM(model.B, ...) or optim = torch.optim.SGD(model.B.parameters(), ...).

BTW, in the provided figure, seems the jump is also in the original trajectory before optimization? So this bug probably has nothing to do with PGO, and I'd recommend to double check the input data.

Hey there. I can have more than one static node.

It will not work even for one static node. This will lead to discontinuities. Since the error is distributed over all the nodes, putting the static one back will lead to the trajectory break.

Can you please elaborate? I've provided the code snippet above of my graph forward path. How can I do that in that snippet specifically?

Regarding the jump in the trajectory - it's not a bug. It is another trajectory that is disconnected from the first one.

Thanks for your reply.

It won't break the trajectory. As I said, you need to transform all nodes using the same transformation. Here is an example: https://github.com/sair-lab/iSLAM/blob/main/pvgo.py
I originally thought that the bug is you have 6 discontinue points at the bottom left of the figure. If this is not the case, which segment is the discontinuity you referred? The other part of the trajectory looks smooth to me.

Thanks for such a quick response.

Thanks, I will have a look. Another thing I was wondering, how in g2o it is allowed to have several static nodes by just passing the is_fixed flag when a node is created. And what would it take to have it "natively" at pypose.

Under discontinuity I mean the big jump that those 6 points at the bottom made. After optimization, those 6 points became so different from the original 6 points.

Hi,

Sorry we do not have this feature now. However, we will soon release the constrained optimizers and they would be helpful for this problem.
I got your point. Yes, the relative location between the two trajectories can change, as there's no constraint between them. You may consider to fix the starting point of both trajectories to solve this issue.

Hi @VladimirYugay,
We just released a new usage for 2nd-order optimizers in v0.6.2. You may update it by pip install -U pypose. It is fully backward compatible.
Basically, you can now return multiple error terms in your model to be optimized. For your case, you may simply return the diff with the ground truth if some specific elements have a fixed value.
        class Model(nn.Module):
            def __init__(self, *dim):
                super().__init__()
                self.pose = pp.Parameter(pp.randn_SE3(*dim))

            def forward(self, poses):
                error1 = ...
                error2 = self.pose[0] - groundtruth
                return error1, error2

For a runnable use case, refer to this test example.


Generated beta models and request builders

This pull request was automatically created by Azure Pipelines. Important Check for unexpected deletions or changes in this PR.

closing since it hasn't been published and we're getting a new PR tomorrow


.Net Bug: In Blazor -  Unhandled Exception: System.NotSupportedException: Synchronous reads are not supported, use ReadAsync instead.

Describe the bug
In .NET 8 this works fine but under Blazor, Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.GetStreamingChatMessageContentsAsync throws an exception.
Unhandled Exception:
System.NotSupportedException: Synchronous reads are not supported, use ReadAsync instead.
at System.Net.Http.WasmHttpReadStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.DelegatingStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at Azure.Core.Pipeline.ReadTimeoutStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.Stream.CopyTo(Stream destination, Int32 bufferSize)
at System.IO.Stream.CopyTo(Stream destination)
at Azure.RequestFailedException.BufferResponseIfNeeded(Response response)
at Azure.RequestFailedException.GetRequestFailedExceptionContent(Response response, RequestFailedDetailsParser parser)
at Azure.RequestFailedException..ctor(Response response, Exception innerException, RequestFailedDetailsParser detailsParser)
at Azure.RequestFailedException..ctor(Response response, Exception innerException)
at Azure.RequestFailedException..ctor(Response response)
at Azure.Core.HttpPipelineExtensions.ProcessMessageAsync(HttpPipeline pipeline, HttpMessage message, RequestContext requestContext, CancellationToken cancellationToken)
at Azure.AI.OpenAI.OpenAIClient.GetChatCompletionsStreamingAsync(ChatCompletionsOptions chatCompletionsOptions, CancellationToken cancellationToken)
at Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.d__551[[Azure.AI.OpenAI.StreamingResponse1[[Azure.AI.OpenAI.StreamingChatCompletionsUpdate, Azure.AI.OpenAI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=92742159e12e44c8]], Azure.AI.OpenAI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=92742159e12e44c8]].MoveNext()
at Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.GetStreamingChatMessageContentsAsync(ChatHistory chat, PromptExecutionSettings executionSettings, Kernel kernel, CancellationToken cancellationToken)+MoveNext()
at Microsoft.SemanticKernel.Connectors.OpenAI.ClientCore.GetStreamingChatMessageContentsAsync(ChatHistory chat, PromptExecutionSettings executionSettings, Kernel kernel, CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()
To Reproduce
Call Microsoft.SemanticKernel.Connectors.**OpenAI.ClientCore.GetStreamingChatMessageContentsAsync running as a Blazor WASM app.
Expected behavior
Works like it does in regular .NET 8
Platform

OS: Windows 11 Version	10.0.22631 Build 22631
IDE: Visual Studio 17.10.3
Language: C#, Blazor WASM app
Source: Microsoft.SemanticKernel Nuget 1.15.0

Additional context
I passed it a new HttpClient like this
var httpClient = new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) };

I am creating the completion service to OpenAI like this (and it works in a Windows WPF app) and throws an exception in Blazor WASM app.
var httpClient = new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) };
chatCompletionService = new OpenAIChatCompletionService(AIService.ModelName, AIService.Key,null,HttpClient);

Some more info:
The Azure.AI.OpenAI dll 1.0.0 beta 17 is not sending the correct JSON to OpenAI endpoint under Blazor. It is missing the Content field in the messages sent.
{"messages":[{"role":"system"},{"role":"user"}],"max_tokens":30000,"temperature":0,"top_p":1,"n":1,"stop":["user:","User:","Question:","ZZ"],"presence_penalty":0,"frequency_penalty":0,"stream":true,"model":"gpt-4o"}

im seeing exactly the same issue using wasm / avaloniaui.. Desktop build is working, wasm is missing message content

Same here, let us know when the fix will be released


bugfix. fix a json mistake.

fix a json mistake.

minor json error affecting examples

@sekaiamber these will go in right away if you do a PR to the livedocs branch, thanks!


Understanding Kafka Topic Partitions / Dunith Dhanushka

URL: https://medium.com/event-driven-utopia/understanding-kafka-topic-partitions-ae40f80552e8
Review (1-2 sentences): I'm a Dunith Dhanushka articles fan: many schemes, easy to read, practical use!

Published in Digest #6.


Add diagnostic output to UndefinedBuildExecutionIntegrationTest

We need to understand what is contributed to a folder that should
be absent.

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.


Small game is added inside java folder

Description
I did the followings changes

Made a separate branch named small-game-in-java
Created folder named small_game
uploaded program file as well as related output
updated README.md to include my program in it

Fixes #388
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] This change requires a documentation update

Checklist:

[x] I have read the contribution guidelines before making this PR.
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented in my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation (Language folder or any other readme instructed to)
[x] My changes generates no new warnings
[x] I have added tests that prove my fix is effective or that my feature works

@kaustubhgupta Sorry for closing this Pull request but i have created a new pull request in which all the above changes are incorporated


omit/pick keys from sub-schema for schema type

is there anyway to achieve below lastMessage type with omitted keys?
Message = new SimpleSchema({
	roomID: {
		type: String
	},
	content: {
		type: String
	},
	...
})

Chatroom = new SimpleSchema({
	lastMessage: {
		type: Message.omit(['roomID']) / Message.pick('content','createdAt')
	},
	...
})

You could use https://atmospherejs.com/lai/simple-schema-omit

Omit and pick were added a long time ago.


Changes for the OpenSpout Excel export

A couple of small changes to the OpenSpout exporter from #332.

Truncate the value when it is larger than the Excel cell limit
Do not wrap text
Decode HTML encoded characters in the value

Alvast bedankt voor het ernaar kijken :)

I'm not sure about the PHPStan failure. It seems unrelated to my PR. Could you look into it?

@curry684 can you please review & merge? Tnx :)

Oops, bit too busy moving offices   😉


Header not showing in new version

I'm using the latest version 7.0
Since I updated to this version had to change how a couple of things work but almost everything is working perfectly, I just can't get the header to work.
I'm implementing both these methods. The size one is the same as previous version, the other is the new one.
func calendar(_ calendar: JTAppleCalendarView, sectionHeaderSizeFor range: (start: Date, end: Date), belongingTo month: Int) -> CGSize {
        return CGSize(width: 0, height: 100)
    }

    func calendar(_ calendar: JTAppleCalendarView, headerViewForDateRange range: (start: Date, end: Date), at indexPath: IndexPath) -> JTAppleCollectionReusableView {
        let headerCell = calendar.dequeueReusableJTAppleSupplementaryView(withReuseIdentifier: "CalendarHeaderView", for: indexPath) as! CalendarHeaderView
        let date = range.start
        headerCell.title.text = DateHelper.monthDateFormatter.string(from: date).capitalizingFirstLetter()
        return headerCell
    }

But no headers show up in the calendar.
I tried adding the supplementary view directly to the collection view in interface builder, and also as a XIB and setting this:
        let nib = UINib(nibName: "CalendarHeaderView", bundle: nil)
        calendarView.register(nib, forSupplementaryViewOfKind: UICollectionElementKindSectionHeader, withReuseIdentifier: "CalendarHeaderView")

But still no header shows up.
Is there something I missing. What else should I do in order to use headers in this new version?
Thanks!

Ok. I have an example app that should explain all attached to Github project.
You register like this:
        calendarView.register(UINib(nibName: "myHeaderView", bundle: Bundle.main),
                              forSupplementaryViewOfKind: UICollectionElementKindSectionHeader,
                              withReuseIdentifier: "myHeaderView")

I have changed the name to resemble exactly a UICollectionView.
func calendar(_ calendar: JTAppleCalendarView, sectionHeaderSizeFor range: (start: Date, end: Date), belongingTo month: Int) -> CGSize {
        return CGSize(width: 0, height: 100)
    }

has been changed to
func calendarSizeForMonths(_ calendar: JTAppleCalendarView?) -> MonthSize? {
    return MonthSize(defaultSize: 200)
}

Awesome, thank you so much!
I was missing this method:
func calendarSizeForMonths(_ calendar: JTAppleCalendarView?) -> MonthSize? {
    return MonthSize(defaultSize: 200)
}

Since this new version just came out I couldn't find any documentation on that.
Thanks for the awesome framework.


How to unmount component when the row is invisible?

First of all, thanks for the great component!
I want to extend some features by React components by CellRenderer like below:
if (col === 0) {
      const dom = document.createElement('div');
      const component = (
        <Provider store={store}>
          <Balloon align="r"
            trigger={{value}}
            closable={false}
            afterClose={() => {

          }}
          >

              <OtherComponent .... />

          </Balloon>
        </Provider>
      );
      ReactDOM.render(component, dom);
      td.innerHTML = '';
      td.appendChild(dom);
    }

It is well rendered when row is visible, and if the row becomes invisible, the DOM element is removed, but the react component is not removed and make memory leaks.
My question is any event or callbacks I should listen on so that I can unmountComponentAtNode properly?

Thanks!
Unfortunately there is none. Our approach is to use LRUMap
https://github.com/handsontable/react-handsontable/blob/bec46ad875f0f20729acba21e1b7009e1d7700b2/src/hotTable.tsx#L97
The map has an event when an item is removed from cache. I don't see it implemented for React, yet. It's a work in progress. It will basically work the same as in our vue wrapper:
https://github.com/handsontable/vue-handsontable-official/blob/6621371767ddf74b2224b54c85559551ed0595f3/src/HotTable.vue#L42-L47

@wojciechczerniak Thanks for the idea! I will have a try.

You can also track #130, components inside cell will be supported by us very soon.


[store-cache] remove bigint serialization once tuple-database supports bigint natively

See https://github.com/ccorcos/tuple-database/issues/25 and https://github.com/latticexyz/mud/pull/810#discussion_r1192990445 for context

store-cache doesn't exist anymore


Add UI or setting to handle different remotes

In the hub, we have two types of contributors:

Those with write access that can use the hub remote
Those without it that must work in their forks

Eventually, people in the latter group will join the first. Sometimes branches on the hub (see my comment in #130) need to be pulled from upstream as well, for people on the 2nd group too. An easy way to configure additional remotes would be really helpful to hub contributors with little git experience.

There is already a command to add new remotes and change the url of existing ones. You can't change the remote of a branch with an existing upstream branch, but if you checkout a new branch, a modal should open to select a remote and branch as upstream branch. I think that's what you need. So I think you are more looking for adding new branches?


clrInput won't trigger validation unless click somewhere else

Describe the bug
Hello team, i met an issue with clr input recently. If using clrInput, it won't trigger validation while type in the input, unless click somewhere else. As long as the error message appears once , it will show directly without any need to click when type something again. This issue not happens if using css input.
How to reproduce
Here is a simple example copied from official site,  both of the two inputs need required validation:
https://stackblitz.com/edit/clarity-angular8-starter-auvjuz?file=src%2Fapp%2Fapp.component.html
Steps to reproduce the behavior:

delete the string in the input box
the css input will trigger validation immediately
the clr input won't trigger the validation for the first time, but will behave normally for the second time and later.

App

Angular: 8
Node: 12
Clarity: 2

Device:

Type: [ MacBook]
OS: [iOS]
Browser: [ chrome]

Hello, this is intentional behavior. The field doesn't validate until it is blurred, otherwise it might throw errors while a user is still trying to put in the right information. For example, if you expect a zip code that is 5 numbers long and 1 number is considered invalid, it would be confusing to invalidate after the first keystroke while they are still trying to type. This is built into the Angular controls, something you can't do with the CSS only versions.
If you need to force validation on a field immediately, you can call markAsTouched() using Angular, and that will tell our validation to display as well.
Closing as intended behavior.

Sorry, i hear you. But, the problem is it only occurs for the first time.
Users don't need to click elsewhere for the second time or third time, just with your example, users can see the validation error at once when they type less than 5 numbers.

Right, that is also expected. Once the field is touched, it validates in real time so once a user puts in the correct value the errors will correct immediately instead of after blur.


Outdated README warning for parallel re-runs

The Warning paragraph in the README > Parallel section does not reflect how Cypress Cloud currently handles re-runs. It also does not distinguish between the different modes of re-running a workflow in the GitHub Actions UI ("Run workflow" used again, "Re-run jobs" > "Re-run failed jobs" and "Re-run jobs" > "Re-run all jobs").
The Warning text is currently:

Warning ⚠: Cypress actions use GITHUB_TOKEN to get the correct branch and the number of jobs run, making it possible to re-run without the need of pushing an empty commit. If you don't want to use the GITHUB_TOKEN you can still run your tests without problem with the only note that Cypress Cloud's API connects parallel jobs into a single logical run using GitHub commit SHA plus workflow name. If you attempt to re-run GitHub checks, Cypress Cloud thinks the run has already ended.  As another work around you can generate and cache a custom build id, read Adding a unique build number to GitHub Actions.

If "Run workflow" is used to repeat the run of a workflow with no changes in it, and GITHUB_TOKEN is passed, then the workflow run is correctly recorded in Cypress Cloud.
If "Re-run jobs" > "Re-run failed jobs" is used then the workflow run will be repeated and recorded in Cypress Cloud, however the full set of Cypress specs are then run in the number of containers which contained failed Cypress specs. "Re-run failed jobs" does not lead to re-running only failed Cypress specs. This needs to be explained.

This text needs to be reworked.
It would also be good to add references to the following capabilities of Cypress Cloud in the context of re-running failed Cypress specs:

Spec Prioritization
Auto Cancellation

I'm not sure if I have enough information to rework the warning, since it describes in part how Cypress Cloud works and this is not open source, so I would be limited to reverse engineering, which is not the ideal basis to provide definitive documentation.
The first step would be in any case for the Cypress (Cloud) team to review this part of the documentation.

@ryanpei Are you still involved in this area, and if so, could you comment?

Thanks @MikeMcC399 , I will try to find someone on our side who knows the exact behavior here. I'm not sure if "Re-run jobs" (as opposed to just the failed jobs, specifically) would re-run only on the containers which had failed. But otherwise this sounds right.

Yes, @MikeMcC399 's suggested edits are correct

@ryanpei
Thanks for your confirmation! Unfortunately since I haven't really understood the original warning text I have great difficulty in revising it sensibly, so I'm not able to resolve this issue on my own.

@MikeMcC399 We used to have issues where users would click 'Rerun jobs' in GitHub Actions and the run would look like it's recording and running, but it essentially just exits 0 and looks like the tests passed, but they didn't run at all. That was because a new unique ci-build-id wasn't generated for each rerun.
If you're not seeing this behavior anymore (that all tests rerun in all situations of rerunning in github-action) then this may have been addressed on the Cloud side. I know they did do some work around better detecting unique identifiers of keys.
If you're seeing the correct behavior on reruns, we can just remove the entire warning section.

@jennifer-shehane

Thanks for your feedback! I have not seen any evidence of the problem you describe still being in existence so I have gone ahead and submitted a PR #1113 which removes the warning section and replaces it will advice about avoiding "Re-run jobs" > "Re-run failed jobs". It also adds a reference to Cloud options:

Spec Prioritization

Auto Cancellation

Note that

https://github.com/cypress-io/github-action/issues/531

is still open.


How to use the '-fix_FIXED_res' parameter in the dl_interface_design_multi_seq.py

Hi Nate,
As far as I know, in the 2-chain hallucination results, the positions of the residues we want to fix are not static in the generated PDB files, they change, and we can see the exact positions of these fixed residues in the trb files. So how should we pass these positions to '-fix_FIXED_res'? As you know, we usually design a lot of proteins and these results are converted to a silent file, and there is no information about these fixed residues in the silent file.
sincerely,
Lei yang

You will have to add FIXED labels to the pdbs before you collect them into a silent file (you can collect these after you have made the silent file but it requires a bit more Rosetta code so I won't go into that here).
You will want to iterate though the pairs of .pdb and .trb files, extract the boolean mask of designed residues and run a loop like this to add residue labels to the .pdb file:
with open('my.pdb.file', 'a') as f:     for resi in range(len(boolean_mask)):         f.write('REMARK PDBinfo-LABEL:%5s FIXED\n'%(resi-1)) # NOTE, these labels must be 1-indexed since they are meant to work with Rosetta which is 1-indexed

@nrbennet Thank you for your prompt reply.
I have written a Python script based on your suggestion, can you help me see if this script conflicts with your suggestion?
Here is my script:
import sys
import os
import glob
import numpy as np
seeds = glob.glob('diffusion/*.pdb')
for seed in seeds:
    trb = np.load(seed.replace('.pdb', '.trb'), allow_pickle=True)
    sample_masks = trb['mask_1d']
    sample_masks = np.array(sample_masks)
    fixed_positions = np.where(sample_masks == True)[0]
    with open(seed, 'a') as f:
        for resi in fixed_positions:
            f.write('REMARK PDBinfo-LABEL:%5s FIXED\n' % (
                        resi + 1))  # NOTE, these labels must be 1-indexed since they are meant to work with Rosetta which is 1-indexed

I found that the generation sequences don't fix the resideus we want to fix.
Maybe the '-fix_FIXED_res' isn't passed to mpnn.

There was a bug in the MPNN script where it was not correctly reading the FIXED labels. This is fixed in the PR today. I have also added a helper script which allows for the simple parsing of RFdiffusion outputs to FIXED residue labels

Thank you for taking the time to fix this bug. I have tried to use the new script. My script is
python3 mpnn_fr/dl_interface_design.py -silent r1.silent \
-output_intermediates \
-checkpoint_path mpnn_fr/ProteinMPNN/vanilla_model_weights/v_48_020.pt \
-omit_AAs 'CX' -fix_FIXED_res
and i get a error like this:
Traceback (most recent call last):
  File "dl_binder_design/mpnn_fr/dl_interface_design.py", line 259, in <module>
    main( pdb, silent_structure, mpnn_model, sfd_in, sfd_out )
  File "dl_binder_design/mpnn_fr/dl_interface_design.py", line 202, in main
    dl_design( pose, pdb, silent_structure, mpnn_model, sfd_out )
  File "dl_binder_design/mpnn_fr/dl_interface_design.py", line 184, in dl_design
    seqs_scores = sequence_optimize( pdbfile, chains, mpnn_model, fixed_positions_dict )
  File "dl_binder_design/mpnn_fr/dl_interface_design.py", line 103, in sequence_optimize
    sequences = mpnn_util.generate_sequences( model, device, feature_dict, arg_dict, masked_chains, visible_chains, fixed_positions_dict )
  File "dl_binder_design/mpnn_fr/util_protein_mpnn.py", line 267, in generate_sequences
    X, S, mask, lengths, chain_M, chain_encoding_all, chain_list_list, visible_list_list, masked_list_list, masked_chain_length_list_list, chain_M_pos, omit_AA_mask, residue_idx, dihedral_mask, tied_pos_list_of_lists_list, pssm_coef, pssm_bias, pssm_log_odds_all, bias_by_res_all, tied_beta= tied_featurize(
  File "dl_binder_design/mpnn_fr/ProteinMPNN/protein_mpnn_utils.py", line 310, in tied_featurize
    fixed_position_mask[np.array(fixed_pos_list)-1] = 0.0
TypeError: unsupported operand type(s) for -: 'dict' and 'int'
Is this a new bug?

I also found another bug.
In the dl_interface_design_multi_seq.py, in line 94.
Is it should be
sequences = mpnn_util.generate_sequences( model, device, feature_dict, arg_dict, masked_chains, visible_chains, fixed_positions_dict )?

The latest PR fixes these. Thanks for pointing this out


Update service.md

@nagajagan Thank you for your contribution. Please sign the CLA so we can accept your PR for review.
/assign

Hi @nagajagan we'd love to review your PR but we haven't heard from you. So I'm going to temporarily close this PR, feel free to reopen when you're ready to continue 😄
/close


Unregister chops-ui package

It was created a day ago. No one is using about it or even knows about it.

done

The old chops-ui package still seems to exist.
I just tried:
bower register chops-ui
and when I run:
bower info chops-ui
I get
bower chops-ui              cached

maybe try "bower cache clean"
bower info chops-ui                                                                                ✘ 127
bower                        ENOTFOUND Package chops-ui not found

Thanks!


Altar cannot be activated if you have an item in your offhand

Not sure what else to say other than it is a bit troublesome to have to unequip a shield/other tool every time when ideally it'd be ignored.

This might be as intended but i think can change it anyway.
Ideally, if you try to give it an item that isnt in ANY recipe it shouldnt even take it


[#440, #487] Conversion of view types and automatic replacing of creatable views by context dependent declared view type

Description

Related Issue

#440 and #487
Motivation and Context

IMO, you are missing a test case that tests conversion of subview mappings. E.g.
@EntityView(Document.class)
public interface DocumentIdView extends Serializable {

    @IdMapping
    public Long getId();

    public SimplePersonView getPeople();

}
@EntityView(Document.class)
public interface DocumentCloneView extends DocumentIdView {
    public PersonView getPeople();
}

When you convert from DocumentCloneView to DocumentIdView, then also the people property should be converted from PersonView to SimplePersonView, right?


Error when run train.py

Hi,
I am trying to regenerate the result, I got the following error. Any help with this?
Thanks
AssertionError                            Traceback (most recent call last)
~/Desktop/projects/VT-UNet-main/train.py in
300     arguments = parser.parse_args()
301     os.environ['CUDA_VISIBLE_DEVICES'] = arguments.devices
--> 302     main(arguments)
~/Desktop/projects/VT-UNet-main/train.py in main(args)
109     optimizer = torch.optim.Adam(params, lr=args.lr, weight_decay=args.weight_decay)
110
--> 111     full_train_dataset, l_val_dataset, bench_dataset = get_datasets(args.seed, fold_number=args.fold)
112     train_loader = torch.utils.data.DataLoader(full_train_dataset, batch_size=args.batch_size, shuffle=True,
113                                                num_workers=args.workers, pin_memory=True, drop_last=True)
~/Desktop/projects/VT-UNet-main/dataset/brats.py in get_datasets(seed, on, fold_number, normalisation)
90     base_folder = pathlib.Path(get_brats_folder(on)).resolve()
91     print(base_folder)
---> 92     assert base_folder.exists()
93     patients_dir = sorted([x for x in base_folder.iterdir() if x.is_dir()])
94
AssertionError:

Hi,
Make sure you have given the correct path for the dataset in the config file.

Hi,
I tried to save the dataset in the dataset folder, and I changed the file path in the config.py, but was not working. Also, I tried to save the dataset as a folder (BRATS2021-Data-BraTS2021_Training_Data), I am trying to follow the file structure;  I understood that I have to have only 2 folders, one for the BRATS2021 and the seconds for the vtunet and save the train.py, test.py, etc inside this folder.
Is that correct?  If not, please tell me the right folder to save the BRATS2021 dataset

You have to rename the folder as in https://github.com/himashi92/VT-UNet/blob/main/config.py#L6 or you can modify the folder path in config.py.


Cleanup after recent refactoring for fix behaviors

Address commentary from https://github.com/apple/swift/pull/59958:

Rename a few ConstraintFix functions to make them more understandable
Sink logic for when to add a fix for concurrency-related issues down into attempt functions on the fixes

@swift-ci please smoke test

@swift-ci please smoke test macOS