Skip to content

Compatibility with Amazon SQS Extended Client Library for Java - #22

Open
sl2000 wants to merge 3 commits into
dvla:masterfrom
sl2000:master
Open

Compatibility with Amazon SQS Extended Client Library for Java#22
sl2000 wants to merge 3 commits into
dvla:masterfrom
sl2000:master

Conversation

@sl2000

@sl2000 sl2000 commented Oct 15, 2025

Copy link
Copy Markdown

I've got a Node.js client that needs to interact with a server using Python. The equivalent Python library to this one https://github.com/awslabs/amazon-sqs-python-extended-client-lib/ and the Java client https://github.com/awslabs/amazon-sqs-java-extended-client-lib/ use a different format for messages using S3 to this Node.js client.

I've logged this as #5

I've added an option compatibleMode which if set to true then....

For sendMessage it uses the Java format - with a numeric attribute ExtendedPayloadSize and the message body changed to a JSON object with the S3 bucket name and key - e.g.:

Attribute: ExtendedPayloadSize Number 424699
Body: {"s3BucketName": "bucket.name", "s3Key": "b03530d9-fae4-493b-a48e-3e1ea969bf1d"}

For receiveMessage it accepts either the original Node.js format or the Java format (and for Java format accepts either ExtendedPayloadSize or SQSLargePayloadSize as the flagging attrribute).

I've also added an option use_legacy_attribute for compatibility with older clients - if set uses the legacy reserved message attribute (SQSLargePayloadSize) instead of the current reserved message attribute (ExtendedPayloadSize) when sending.

With compatibleMode not set then the library behaves as before.

I've not added tests for these new options. Could do if pull request accepted.

This supersedes my earlier pull request #6. I'd be much obliged if you could merge this in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants