1 回答
- 最新
- 投票最多
- 评论最多
0
How did you check that retention is not accurate?
Due to the distributed nature of SQS, ApproximateReceiveCount is only an approximation (as it names implies). Different hosts can have different values.
What you are doing is not consider recursive invocation. A recursive use case if if your function sends the messages back to the same queue. This can cause an infinite loop. Not deleting the message from the queue is not a recursive operation as eventually it will either hit the maximum retries or will expire from the queue.
Instead of failing your function, you can just return an array with partial batch responses.
相关内容
- AWS 官方已更新 7 个月前
- AWS 官方已更新 2 个月前
- AWS 官方已更新 2 年前
- AWS 官方已更新 1 年前
How did you check that retention is not accurate? -> We have a retention set on queue of 4 days. But we observed that message is being retained for than 4 days by looking at logs for specific message id.
We received recursive invocation mail from aws hence it is considered as recursive invocation. Before failing the execution, visibility timeout of message is increased and then execution is failed, that way message stays in the queue but invocation counter is increased.
Is there any way to keep the message in the queue without becoming a case for recursive invocation?
This is strange. Not handling a message is not a recursion. I am guessing that you are sending the message to the queue again yourself. This will explain the recursion message you got as well as the fact that it stays for more than 4 days. Can you share your code?