Gaurav-Aggarwal-AWS

Thank for your request. These are very helpful to us during prioritization of our work.

Thank you for the proposal @cperkulator. We can avoid expanding the API surface so much if we consider blocking buffer a special type of stream buffer: ``` #define xStreamBufferBlockingCreate( xBufferSizeBytes,...

> Why is it never set anywhere in the code? Shouldn't a PUBACK trigger the LAST_PACKET_RX_TIME to be set correctly? `lastPacketRxTime` is updated here - https://github.com/FreeRTOS/coreMQTT/blob/main/source/core_mqtt.c#L1794. Likely the coreMQTT submodule...

@davdwsl Did you get a chance to try out the above suggestions?

@davdwsl Thank you for reporting. I am closing this issue. Feel free to reopen or open a new one if you need anything else.

Can you check what does your [transport send/writev function](https://github.com/FreeRTOS/coreMQTT/blob/main/source/core_mqtt.c#L798) return? If it returns success, MQTT has no way to determine that the data was not actually sent. In that case...

> set qos1 or add some other code to check the return msg? That should help to catch broken connection.

This case is handled here - https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/tasks.c#L2841 Are you facing any problem with round robin scheduling of equal priority tasks?

> And, that will remain the default case, right? Yes - https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/include/FreeRTOS.h#L888 Here is the description of the `configUSE_TIME_SLICING` which describes the intended behavior - https://www.freertos.org/a00110.html#configUSE_TIME_SLICING This PR just fixes...

This is fixed here - https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/main/portable/GCC/ARM_CA53_64_BIT_SRE