[BUG] processOTAEvents() stops cycling through if OtaReceiveEvent_FreeRTOS( &recvEvent ) does not retrieve a valid OTA event

[idea--list]

Describe the bug
I'm migrating to the esp-aws-iot [202406.01-LTS] from [202210.01-LTS].
My project is based on ESP32S3 MCU. Program logic is based on the temp_sub_pub_and_led_control_demo and on ota_over_mqtt_demo examples. Also applied the solution of @fjuliofontes for the issue #120 .

My observation:

• when the board restarts, it communicates to AWS IoT's OTA relevant topics.
• this initial communication takes only a few seconds and if there is no OTA being rolled out to the device, then i see this output on the console: ota_over_mqtt_demo: This is not an OTA job.
• If i initiate an OTA update from AWS IoT console after the above message, the device will not begin downloading the update, as prvOTADemoTask gets stuck inside processOTAEvents() loop because if (OtaOsSuccess == OtaReceiveEvent_FreeRTOS( &recvEvent )) can not retrieve anything to work on inside the switch( recvEventId ) after the above message on the console.
• If however i press the reboot button on the hardware or send an MQTT message to the board from IoT console that triggers esp_restart(), then the board will recognize the pending update and download that. But again only in the few first seconds after restarting the board.

Expected behavior
I expect that the program logic does not lock up inside switch( recvEventId ) when there is no pending OTA update available right at the beginning.

Steps to reproduce bug
1. Start the device, wait until you see ota_over_mqtt_demo: This is not an OTA job on the console
2. Initiate an OTA update job from AWS IoT console
3. Observe the device not recognizing the pending update no matter how long you wait
4. Press reboot button on the board (or trigger an esp_restart()) and watch it grabbing the update

[idea--list]

Found a fix:

inside processOTAEvents() we have to modify this part

case OtaPalJobDocFileCreateFailed:
case OtaPalNewImageBootFailed:
case OtaPalJobDocProcessingStateInvalid:
    ESP_LOGI( TAG, "This is not an OTA job \n" );
    break;

like this

case OtaPalJobDocFileCreateFailed:
case OtaPalNewImageBootFailed:
case OtaPalJobDocProcessingStateInvalid:
    ESP_LOGI( TAG, "This is not an OTA job \n" );
    vTaskDelay( pdMS_TO_TICKS( 60000 ) );
    nextEvent.eventId = OtaAgentEventRequestJobDocument;
    OtaSendEvent_FreeRTOS( &nextEvent );
    break;

After that the device will keep negotiate with IoT every 60 seconds if there is a new update intended for the device.
Feel free to change the delay to whatever fits your needs but keeps polling data traffic to AWS IoT low enough.

[idea--list]

Turns out people already reported this bug many times before. This just shows it was not a good idea to change a behaviour people are used to and also should happen automatically. The whole point of OTA updates is that the device does not have to poll the server for any updates.

Also for security reasons the server pushes the updates and not the devices poll for it...