Compatibility issue with native SQS Java Extended Client

[AndrewWinDev]

I'm having issues using this library with a native Java Amazon Extended Client Library on another end. Java client uses the next message body format for big messages, stored on S3, for the S3Pointer:

[
  "software.amazon.payloadoffloading.PayloadS3Pointer",
  {
    "s3BucketName": "extended-client-bucket",
    "s3Key": "xxxx-xxxxx-xxxxx-xxxxxx"
  }
]

But this library expects there just plain MessageS3Pointer object

{
  "s3BucketName": "extended-client-bucket",
  "s3Key": "xxxx-xxxxx-xxxxx-xxxxxx"
}

So, it fails on deserialization of SQS message that stores original payload on S3 by Java client.

As it stated that this library is a "port to .NET of existing Amazon Extended Client Library for Java", I would expect that they should be compatible so, I can send big messages on one end by Java client and receive them on another, using .Net client (this library)

So, is it possible to align messages formats or at least make it configurable to be able to work with Java client as well?

Thanks, Andrew.

[cboudereau]

Hi, the golang implementation equivalent of the sqs extended client is compatible with the weird java implementation : https://github.com/jwcorle/sqs-extended-client-go/blob/main/client.go#L201

TBH, I find that putting language namespace inside the json is strange, I find that the issue should be fixed in the java implementation but since it is used, I think that other libraries should support this compatibility