Unfortunately telemetry messages that are resent by the MQTT transport
are not marked with the DUP flag as TRUE (as should by spec MQTT-3.3.1-2).
Note that telemetry messages are always sent by the azure-iot-sdk-c MQTT
transport with QOS1, so no control is necessary for the DUP flag related to QOS0.
azure-iot-sdk-c's MQTT transport does not attempt ot resend TWIN messages
or direct methods responses, so this fix does not apply to these
messaging features.
Related issue: https://github.com/azure/azure-iot-sdk-c/issues/2514
Internal headers must not be referenced by any public header.
The recent u2b changes caused iothub_client_core_ll.h to
include internal/iothub_client_ll_uploadtoblob.h, which is incorrect.
This fix removes this include directive from iothub_client_core_ll.h and
moves the type IOTHUB_CLIENT_LL_UPLOADTOBLOB_HANDLE into
iothub_client_core_common.h, solving the need for both client layer and
upload-to-blob modules to reference this type.
The ARM and the MIPS32 cross-compilation jobs in .vsts-ci.yml will always target the main branch,
ignoring the branch a given PR is based on and letting potential issues sip through.
This change fixes the ARM and MIPS32 jobs so they run against whatever branch the pipeline is running
against.
* Add more granular upload-to-blob functions, refactor u2b code
* [ACR] Expose upload-to-blob correlation ID and SAS URI in new API functions
* Address code review comments (2)
* Update unit tests for blob.c
* Update iothub_client_ll_u2b_ut
* Update iothub_client_ll_u2b_ut (continued) and other fixes
* Update iothub_client_ll_u2b_ut (continued 2)
* Update iothub_client_ll_u2b_ut (continued 3)
* Update iothub_client_ll_u2b_ut (continued 4)
* Updates to iothub_client_core_ll_ut
* Updates to iothub_client_core_ll_ut (continued)
* Additional unit test fixes
* Fix return of blob result in iothubclient_ll_u2b_ut
* Fix size_t to int conversion in iothub_client_ll_uploadtoblob.c
* Add fixes for clang build
* More fixes for clang and windows builds
* Fix DONT_USE_UPLOADTOBLOB guards in code
* More build and test fixes
* More build fixes
* More test fixes in iothub_client_ll_u2b_ut for OSX pipeline
* Reduce number of iterations of IoTHub_MQTT_UploadCloseHandle_Before_WorkersComplete
* Address CR comments from Eric
* Add retry logic to iothub_client_sample_upload_to_blob_custom
* Address code review comments (function renaming)
* Verify and log http response status code in u2b functions
* Update blob_ut
* Address final CR comments
This change fixes a memory corruption caused by message queue when the
following scenario occurs:
MESSAGE1 is enqueued (address #0001)
MESSAGE1 is put in progress by mq
MESSAGE1 is destroyed by the app
MESSAGE2 is enqueued (re-using address #0001, which was made available
by the previous step)
MESSAGE2 is put in progress by the mq
MESSAGE2 processing is marked as completed by the app
> Here the message queue searches the list of in-progress messages by
the message address in memory. Since MESSAGE2 now has the same address
of MESSAGE1 (which was freed), message_queue picks the entry for
MESSAGE1 for removing from the in-progress list, leaving MESSAGE2
behind.
* Fix data type of error code for Upload to Blob error responses
* Fix data type of error code for Upload to Blob error responses
* Add E2E test to verify when upload is aborted
In iothubtransport_amqp_common.c `number_of_previous_failures` is used to track issues with the AMQP device and either restart or re-connect it as appropriately.
Note: AMQP device (iothubtransport_amqp_device.c) is a subcomponent of the AMQP transport, representing each registered device.
The AMQP transport can either just restart a registered AMQP device (causing just re-ATTACH-ment of AMQP links) or completely reconnect it (with END, CLOSE, OPEN, BEGIN, ...).
When a failure occurs (e.g., the Twin messenger reports an error), the AMQP device goes into an error state itself and `number_of_previous_failures` (on AMQP transport layer) is incremented.
If `number_of_previous_failures` is less than `MAX_NUMBER_OF_DEVICE_FAILURES`, the AMQP device is just restarted.
If `number_of_previous_failures` reaches `MAX_NUMBER_OF_DEVICE_FAILURES`, the AMQP device is completely reconnected.
If `number_of_previous_failures` never reaches `MAX_NUMBER_OF_DEVICE_FAILURES` (iothubtransport_amqp_common.c:1058) then the transport will never force a full reconnection, always trying to stop the registered AMQP device.
When IoTHubTransport_AMQP_Common_Device_DoWork is called (for each registered device), if `send_pending_events` succeeds, `number_of_previous_failures` is set to 0.
But all `send_pending_events` does is to add a message on the outgoing queue of the AMQP messenger, so it is always expected to succeed, always resetting `number_of_previous_failures`.
That prevents in such case the AMQP transport from fully reconnecting with the IoT Hub in specific error scenarios - like when the Twin throttling occurs, causing outgoing Twin messages (e.g, PATCH, i.e., reported properties update) to fail.
The AMQP transport keeps trapped in a loop of just trying to restablish the AMQP links in in this case.
The macro name 'PROV_TRANSPORT_AMQP_COMMON_H' was used in two header files: prov_transport_amqp_common.h and prov_transport_mqtt_common.h.
The new macro name 'PROV_TRANSPORT_MQTT_COMMON_H' is created for prov_transport_mqtt_common.h.
Eric Wolz
Ewerton Scaboro da Silva
Raul Leclair
Valerie Avva Lim
Cristian Pop
Mingjie Shen