1 Respuesta
- Más nuevo
- Más votos
- Más comentarios
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.
Contenido relevante
- OFICIAL DE AWSActualizada hace un año
- OFICIAL DE AWSActualizada hace 7 meses
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?