You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have found an issue when we try to confirm our messages have been processed using a FIFO SQS extended.
When the delete happens it is basically deleting iniatially from the S3 bucket and after that's done it tries to remove from the queue, basically an AmazonSQSException is raised saying the ReceiptHandler is expired, and as a result the message stays in the queue, however the payload is correctly deleted from the S3 bucket.
As a result the message is repicked by the queue and when it does try to read it again an AmazonS3Exception is raised saying there is no payload related to the message from the queue.
I think the delete operation should be somehow atomic as the message in the queue means nothing without the real content from S3.
We have experimented around changing the order of the operations, so removing first from the queue and later on the S3 bucket and it works better, but from our point of view this should be provided by the API itself.
Let me know if you need any further information.
The text was updated successfully, but these errors were encountered:
We have found an issue when we try to confirm our messages have been processed using a FIFO SQS extended.
When the delete happens it is basically deleting iniatially from the S3 bucket and after that's done it tries to remove from the queue, basically an AmazonSQSException is raised saying the ReceiptHandler is expired, and as a result the message stays in the queue, however the payload is correctly deleted from the S3 bucket.
As a result the message is repicked by the queue and when it does try to read it again an AmazonS3Exception is raised saying there is no payload related to the message from the queue.
I think the delete operation should be somehow atomic as the message in the queue means nothing without the real content from S3.
We have experimented around changing the order of the operations, so removing first from the queue and later on the S3 bucket and it works better, but from our point of view this should be provided by the API itself.
Let me know if you need any further information.
The text was updated successfully, but these errors were encountered: