awslabs / aws-mobile-appsync-sdk-android

Android SDK for AWS AppSync.
https://docs.amplify.aws/sdk/api/graphql/q/platform/android/
Apache License 2.0
105 stars 58 forks source link

Mutation request submitted twice for long running task - disable auto retry. #309

Open moin-eatclub opened 4 years ago

moin-eatclub commented 4 years ago

Describe the bug Mutation request is submitted twice when backend takes a while to return the response or internet connection is slower. It works when backend returns result quickly.

How to disable mutation retry policy? i.e. submit mutation only once or fail.

To Reproduce Steps to reproduce the behavior:

  1. Create AppSyncClient
    private static volatile AWSAppSyncClient client;
    public synchronized static AWSAppSyncClient getInstance(Context context) {
        if (client == null) {
            AWSConfiguration awsConfig = new AWSConfiguration(context);
            client = AWSAppSyncClient.builder()
                    .context(context.getApplicationContext())
                    .awsConfiguration(awsConfig)
                    .build();
        }
        return client;
    }
  2. Submit mutation request
    client.mutate(mutation)
          .enqueue(new ...
  3. Make sure backend executes a long-running task > 10-15 seconds.
  4. The same mutation request is submitted twice.

Expected behavior Mutations must not be submitted twice. Disable retry policy for mutations.

Environment(please complete the following information):

Device Information (please complete the following information):

jamesonwilliams commented 4 years ago

I believe the best solution will be for the AppSync service to enforce idempotent service in their service APIs. The client should attach a request ID for outbound requests. For the situation described in this issue, the client will use the same request ID, so AppSync will know that it is being asked to do the same logical work, and will reject the second request.

dinnerdeal commented 3 years ago

Anyone have any update on this one? Pretty critical one. We're seeing multiple triggers of mutations.

CorainChicago commented 2 years ago

This issue is still ongoing. The freedom to calibrate or disable retry logic is still needed. Some services have expected processing time, where matching the expected time to the need for an automatic retry is a business need.

ds24449 commented 1 year ago

Hi Team,

The freedom to calibrate or disable retry logic is still needed.

is there any update on this ? We are trying to use AppSync in our Android App and we wanted to use custom retry policy. From the code seems like even if we define our own OkHttp client, the RetryInterceptor will override it anyways.