Closed nitesh237 closed 9 months ago
Thanks for the report - I could reproduce this in gresau/localstack-persist:3.0.2
, but not in gresau/localstack-persist:latest
. After digging a bit further, I found that this would only occur when running localstack-persist based on LocalStack 3.0.1, and it did not occur when using a base image of LocalStack 3.0.2.
I've now published localstack-persist:3.0.3 which is based on LocalStack 3.0.2 (which to be honest I should have done a while ago), so that should fix your problem. Could you give it a try?
I couldn't find exactly what changed in LocalStack to break/fix this behaviour, but I'm fairly sure it's something to do with the updates in 3.0 to add support for the JSON SQS protocol that's used by newer versions of the AWS SDK. This bug seemed to only occur when using older SDKs, which includes awslocal
. This also explains why this bug was unfortunately not caught by localstack-persist's automated tests - as part of the tests, a create-queue request is made using the JSON API, which causes persistence to work.
Hey @GREsau, thanks a lot for spending time here. It's working in version 3.0.3
.
Hello,
Firstly, I want to express my gratitude for your efforts in maintaining the persistence of LocalStack.
After trying out the latest version of the LocalStack container, it seems that SQS persistence is currently broken. I encountered that SQS states aren't persisting when attempting to restart or stop the container.
Here are the details of my environment:
Steps to Reproduce:
/persisted-data
as recommended in the README. Here is the compose file that I have been using.Expected Behavior:
Actual Behavior:
persisted-data
, I could only see the states from sns and s3 services in place.This issue is critical for our integration testing suits. If there's anything else needed from my end, please let me know. I appreciate your time and attention to this matter.