connectCases:Add retry if created customer or case is not immediately available about aws-sdk-net HOT 6 OPEN

Hello @michael-freidgeim-webjet,

AWS services, including AWS Connect, operate on the principle of eventual consistency. So, immediately after creating a customer or case, it might not be available yet through the API.

Having said that, we've created an internal ticket-V1422063706 with the Amazon Connect Docs team, requesting them to improve the documentation around eventual consistency and how to handle potential delays when querying recently created data.

I will mark this as Closing-soon. Kindly let me know if you have further queries.

Thanks again for providing your feedback on the encountered issue.

Regards,
Chaitanya

from aws-sdk-net.

@michael-freidgeim-webjet Good morning. Thanks for opening feature request. The default retry mechanism would retry only on specific throttling and service timeout error codes. It is more generic and is handled at the Http pipeline level, which cannot be selectively used for specific service error codes (such as case not found for your use case). The probably cause for your issue is that after a case is created, it might take some time to replicate across different AWS regions. Hence, if you immediately invoke service operation for the specific case, it might not return results as expected.

Also note that the package AWSSDK.ConnectCases is auto-generated from service models. Hence it might not be feasible to add additional parameters to methods generated by from the service models. You might want to develop a wrapper package for your specific use case to add this retry mechanism for specific operations.

I would review this with the team to check if there is any other workaround.

Thanks,
Ashish

from aws-sdk-net.

Thanks @ashishdhingra for your reply.
“Hence it might not be feasible to add additional parameters to methods generated by from the service models. You might want to develop a wrapper package for your specific use case to add this retry mechanism for specific operations.”
We’ve already implemented the retry mechanism in our code However the problem is not specific to our project and even to .Net, and will be beneficial, if it will be resolved by Amazon, rather that each team will resolved it by themselves after hitting intermittent errors.
By the “service model” do you mean rest api contract documented in https://docs.aws.amazon.com/connect/latest/APIReference/API_connect-cases_CreateCase.html ?
If yes, the parameter should by added to the service model to be available for any language implementation.

from aws-sdk-net.

Thanks @ashishdhingra for your reply. “Hence it might not be feasible to add additional parameters to methods generated by from the service models. You might want to develop a wrapper package for your specific use case to add this retry mechanism for specific operations.” We’ve already implemented the retry mechanism in our code However the problem is not specific to our project and even to .Net, and will be beneficial, if it will be resolved by Amazon, rather that each team will resolved it by themselves after hitting intermittent errors. By the “service model” do you mean rest api contract documented in https://docs.aws.amazon.com/connect/latest/APIReference/API_connect-cases_CreateCase.html ? If yes, the parameter should by added to the service model to be available for any language implementation.

@michael-freidgeim-webjet Service API models are pushed to downstream SDK systems from service teams. For .NET SDK, these are available here. The API operation definition specifies parameters required for operation, including any exception that is thrown by the service. The retry behavior is specific to downstream SDK(s), which define retry behavior for specific AWS service error codes, including throttling and timeout errors. Hence, the specific parameter as you suggested cannot be supported at API level as this not required for API operation, but instead client level implementation.

Thanks,
Ashish

from aws-sdk-net.

@ashishdhingra Thanks for explaining separation of concerns between the Service API and SDK. Service API returns exception and SDK implements retries for some known types of exceptions. SDK currently doesn’t have a mechanism to specify extra retry behavior on individual call level, but only on ClientConfig level for some known exceptions.

The problem is that the intermittent issue is not an exception of singe call and may be a genuine “not found” return. If application developer knows that the record has been created just millisecond before as a result of previous call, they should consider “not found” as a reason for retry.

If it is not feasible to implement, please consider to add a note in the documentation for individual operations, that may experience such issue, e.g.

If related objects(e.g. customer profile or case) are created just before the method call, they maybe not found immediately, as it might take some time to replicate across different AWS regions. If you experience (or likely to experience) such issue, consider to implement retry/delay mechanism for your call.

from aws-sdk-net.