Closed kjc-heliosx closed 1 year ago
Maybe related to the issue with s3 in quickstarts https://github.com/quarkusio/quarkus-quickstarts/pull/1257
I guess LocalStack v2 now starts all services at boot and this is why it takes more time to boot. Default timeout is 60s. If you want to try waiting more, set quarkus.devservices.timeout
property.
Dynamodb seems to work with newer tag 2.0.1
In that case possibly an upstream bug and this issue can be closed, I'll give it a try myself on my minimal repo
Indeed, fixed for me in 2.0.1, it just takes a while, probably can be fixed with config though, closing this, someone can reopen if they have more issues.
It appears that on quarkus 3 CR2, or perhaps more generally currently localstack is pinned to 2.0.0, which is now the latest version. You pin it to 1.0.3 in your integration tests. https://github.com/quarkiverse/quarkus-amazon-services/blob/main/integration-tests/src/main/resources/application.properties
When setting
quarkus.aws.devservices.localstack.image-name=localstack/localstack:2.0.0
or indeed leaving it blank, a simple test case persisting to dynamodb fails, because localstack hasn't had enough time to boot yet.When running master with the image pinned to 2.0.0 the integration tests fail for the same reason.
I have opened https://github.com/quarkiverse/quarkus-amazon-services/pull/640 to demonstrate this.
It's possible this is an upstream issue, but you guys should be aware of it, it left me a little confused.