moto: Creating of SQS queues with latest botorecore (1.29.127) is broken
Hello moto team,
Looks like moto is broken with the latest botocore (1.29.127) as AWS has changed the format for interacting with some services (includig SQS). When creating a SQS queue, it returns {} rather than a Queue object (I use a SQS resource).
I have opened an issue in their tracker (see https://github.com/boto/botocore/issues/2930) but it looks like moto might need to make some changes too.
You can reproduce the issue with:
import moto
import boto3
from uuid import uuid4
@moto.mock_sqs
def test_create_queue():
sqs = boto3.resource("sqs", region_name="us-east-1")
q_name = str(uuid4())[0:6]
new_queue = sqs.create_queue(QueueName=q_name)
print(new_queue)
test_create_queue()
With pip install boto3==1.26.126 botocore==1.29.126 moto, the output is sqs.Queue(url='https://sqs.us-east-1.amazonaws.com/123456789012/a94c6c').
With pip install boto3==1.26.127 botocore==1.29.127 moto, the output is {}.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 25
- Comments: 16 (3 by maintainers)
Commits related to this issue
- Temporarily limit botocore upgrades The latest botocore (1.29.127) breaks the way moto creates SQS queues and we need to limit it temporarily so that it will not fail our tests. Related: https://git... — committed to potiuk/airflow by potiuk a year ago
- Temporarily limit botocore upgrades (#31098) The latest botocore (1.29.127) breaks the way moto creates SQS queues and we need to limit it temporarily so that it will not fail our tests. Related... — committed to apache/airflow by potiuk a year ago
- Temporarily limit botocore upgrades (#31098) The latest botocore (1.29.127) breaks the way moto creates SQS queues and we need to limit it temporarily so that it will not fail our tests. Related: ht... — committed to GoogleCloudPlatform/composer-airflow by potiuk a year ago
Moto >= 4.1.11.dev7 now also supports both JSON and XML responses. It will return the appropriate format based on the ContentType-header.
So when AWS re-enables this feature, we should be ready.
@JayThomason it’s botocore - what you’re seeing is that boto3 1.26.x will use any available version of botocore that is > 1.29.x and < 1.30.0, whereas boto3 1.15.x will use any available version of botocore that is > 1.28.x and < 1.29.0.
So any install of boto3 1.26.x will pick up botocore==1.29.127 (or later) which has the breaking change, whereas any install of boto3 1.25.x will pick up botocore==1.18.5 and work.
This was gnarly for me, because all of my requirements.txt specification are on fixed versions, so I was surprised to see builds suddenly failing with no changes made.