[SQS] Invalid exception when receipt handler is invalid in changeMessageVisibility

[fededonna]

When we send an invalid message handler the contract of the api is saying that we should get back an ReceiptHandleIsInvalidException but instead we are receiving this:

com.amazonaws.services.sqs.model.AmazonSQSException: Value AQEB4Th3fRVytfInC2x4LE5Em5fSzVE3uR9Ozd3Uu1i3lJvSqERwa7U8+MrImfU+zhCUs7Z4DW9zKZevarJPxp5MnTLsqAs1M/hrr7+jNL/Oc32/IjKF5RFOR7EPriir5m/GFmHpN947EcBZs5qMIbg8msEaZljuTqmGA47kWeMfDa5LJHhYxLSLJXJOZTBcL5TbOQJOqGmulqNHacf85U34KWZuwksqsJF5nFmi5sADVcBq/Tqn0qaEFycoQ6mgGob66uIPZSCWrYYuJEuwIzs06kwJm84OA1m3A+OcPdPM7xmfeqCMEeGHaKB5VnNt3dv5 for parameter ReceiptHandle is invalid. Reason: The receipt handle has expired. (Service: AmazonSQS; Status Code: 400; Error Code: InvalidParameterValue; Request ID: 0bd103e8-6a07-5df6-be0e-50733c68afbf)

[varunnvs92]

I found two different error cases:

1. When a random value is given as receipt handle
   Service returns "ReceiptHandleIsInvalid" error code. Hence SDK returns ReceiptHandleIsInvalidException

2. When an expired receipt handle is given as input
   Service returns "InvalidParameterValue" error code. As this is not a modeled error code, SDK returns base sqs exception which is AmazonSQSException

This is a server side issue. I will open an internal ticket with the service team and follow up with you.

[fededonna]

Can you, as the contract says, manage that error as ReceiptHandleIsInvalid? since it's expired it's invalid and the contract remains the same.

[varunnvs92]

We generate the clients from the models provided by the service side. We currently don't do special handling of errors. Even if we can, we don't want to do it in this case as this would introduce inconsistency across other language SDKs.
To proceed further, I need to clarify if this is an intended behavior from the service end. In addition, docs says ReceiptHandleIsInvalid is thrown if specified receipt handle isn't valid. Its possible that our interpretation of this statement might be different that what service team intended. I would wait until service team comes back with a reply.

[fededonna]

Have in mind that an expired receipt handler is an invalid receipt handler.

[varunnvs92]

Response from service team:

Hey - I believe the current error codes are correct.

ReceiptHandleIsInvalidException - The receipt handle provided isn't valid. - HTTP Status Code: 404
-> This is returned when the value provided isn't a real receipt handle. It doesn't refer to the correctness of the handle's contents (with-respect-to its constraints), just that it's actually a real, parsable receipt handle.

InvalidParameterValue - An invalid or out-of-range value was supplied for the input parameter. - HTTP Status Code: 400
-> This is applicable here because of the "out-of-range" aspect; a real receipt handle was provided, but its contents have already expired.

[fededonna]

Please, I encourage you to check the API, that is not part of the contract.

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html

Also the Status code of ReceiptHandlerIsInvalidException is not 404.

[varunnvs92]

The docs are incorrect and Service team will fix them. If you enable wire logs, you will get 404 for ReceiptHandleIsInvalid error. The current error codes are correct for the respective behaviors. Thanks for noticing the issue and reaching out to us.

[fededonna]

So what is the final solution? they will fix that in the backend and the new sdk will have this fix? The error will be ReceiptHandlerIsInvalidException or will still be the generic one?

[varunnvs92]

The current behavior is correct and There will not be any change in the behavior. The expired receipt handle will return the InvalidParameterValue error.

[fededonna]

So to identify what the problem is I have to introspect a String? I think the SDK needs to be more clear. An expired handler is an invalid handler.

[varunnvs92]

I understand that the distinction between these two cases is limited and can change vary on the interpretation. But as per service team's context:

1. A invalid receipt handle is some arbitrary value that doesn't satisfy the requirements for a receipt handle.
2. An expired receipt handle is a valid receipt handle (as it satisfies the constraints) but its expired/out of range. So InvalidParameterValue is sent which is a common error in SQS.

[fededonna]

What I don't like about that is that you know exactly what happened but still you throw a generic exception that can happen because of this or because the expiration time sent is < 0 or a lot of different reasons and the only way to tell is to introspect a string. I'm pretty sure that given the quality of the SDK you can do better than that.

[varunnvs92]

I understand your concern. But as I mentioned, we don't want to change the SDK to throw a different exception than the error sent by service. These kind of customizations confuse customers and introduce inconsistency with other language SDKs.
As from service perspective, they have internal limitations (can't discuss) that led to use the current error codes. As of now, they don't have plans to change these error codes.
Thank you.