-
Hello Samli,
Good Day!
Let’s review the scenario. The visibility timeout is set to 1 hour, which means if a message takes longer than 1 hour to process, it will reappear in the queue. Given that the processing time is only 20-40 minutes, a 1-hour visibility timeout is more than sufficient. The dead-letter queue received several videos that failed to process, but there were no operational errors and no videos exceeded the expected processing time as mentioned in the scenario. This suggests that the problem lies not with the processing time but with the retry attempts. It could also means that other situations cause errors to not show up in the application logs like transient network issues. The scenario also indicates repeated ReceiveMessage API calls for specific videos, pointing to retry attempts as the issue. Which also relates to the maxReceiveCount that was set to 1, meaning that if a message fails to process on its first attempt, it is sent to the dead-letter queue.
Extending the visibility timeout to 2 hours could prevent messages from being prematurely retried before processing, but it doesn’t address the core issue related to retry attempts and the current visibility timeout should already provide sufficient time for the messages to be processed without becoming visible again for reprocessing. Therefore, increasing the maxReceiveCount to 10 would allow the system to retry processing the message multiple times before sending it to the dead-letter queue. This change would handle transient issues or temporary delays more effectively without altering the visibility timeout.I hope this clarifies your question. If you need any further clarification, please let us know.
Regards,
Neil @ Tutorials Dojo
