versions 2.10.60 and above of sdk throw InternalServerError exception when using DynamoDB transactions

Describe the bug

We have a very comprehensive set of System Tests that we have been running for the last 18 months. We recently upgraded the aws-sdk from version 2.10.56 to 2.13.25 and our our test suite began to fail with occasional calls to transactWriteItems. Our test suite calls transactWriteItems hundreds of times and only fails maybe once or twice. I reran the test suite numerous times with version bisection from 2.10.56 to 2.13.25 which failed with the same transactWriteItems failure each time untilI reached 2.10.59 which succeeded. Our test suite (which has been running for some time) now passes every time with 2.10.59 but fails with a transactWriteItems on every version since then.

Expected Behavior

I expect the same test suite to pass (reasonably consistently) with versions of the sdk since 2.10.59

Current Behavior

The tests fail with a least one InternaServerError from transactWriteItems on every run with any version since 2.10.60 - the same tests pass every time with 2.10.59

Example stack trace Internal server error (Service: DynamoDb, Status Code: 500, Request ID: KDGNGE98O67GG0VUO7E0GG88VRVV4KQNSO5AEMVJF66Q9ASUAAJG): software.amazon.awssdk.services.dynamodb.model.InternalServerErrorException software.amazon.awssdk.services.dynamodb.model.InternalServerErrorException: Internal server error (Service: DynamoDb, Status Code: 500, Request ID: KDGNGE98O67GG0VUO7E0GG88VRVV4KQNSO5AEMVJF66Q9ASUAAJG) at software.amazon.awssdk.core.internal.http.CombinedResponseHandler.handleErrorResponse(CombinedResponseHandler.java:125) at software.amazon.awssdk.core.internal.http.CombinedResponseHandler.handleResponse(CombinedResponseHandler.java:81) at software.amazon.awssdk.core.internal.http.CombinedResponseHandler.handle(CombinedResponseHandler.java:61) at software.amazon.awssdk.core.internal.http.CombinedResponseHandler.handle(CombinedResponseHandler.java:42) at software.amazon.awssdk.core.internal.http.pipeline.stages.HandleResponseStage.execute(HandleResponseStage.java:40) at software.amazon.awssdk.core.internal.http.pipeline.stages.HandleResponseStage.execute(HandleResponseStage.java:30) at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206) at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallAttemptTimeoutTrackingStage.execute(ApiCallAttemptTimeoutTrackingStage.java:74) at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallAttemptTimeoutTrackingStage.execute(ApiCallAttemptTimeoutTrackingStage.java:43) at software.amazon.awssdk.core.internal.http.pipeline.stages.TimeoutExceptionHandlingStage.execute(TimeoutExceptionHandlingStage.java:78) at software.amazon.awssdk.core.internal.http.pipeline.stages.TimeoutExceptionHandlingStage.execute(TimeoutExceptionHandlingStage.java:40) at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage$RetryExecutor.doExecute(RetryableStage.java:114) at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage$RetryExecutor.execute(RetryableStage.java:87) at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage.execute(RetryableStage.java:63) at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage.execute(RetryableStage.java:43) at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206) at software.amazon.awssdk.core.internal.http.StreamManagingStage.execute(StreamManagingStage.java:57) at software.amazon.awssdk.core.internal.http.StreamManagingStage.execute(StreamManagingStage.java:37) at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallTimeoutTrackingStage.executeWithTimer(ApiCallTimeoutTrackingStage.java:81) at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallTimeoutTrackingStage.execute(ApiCallTimeoutTrackingStage.java:61) at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallTimeoutTrackingStage.execute(ApiCallTimeoutTrackingStage.java:43) at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206) at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206) at software.amazon.awssdk.core.internal.http.pipeline.stages.ExecutionFailureExceptionReportingStage.execute(ExecutionFailureExceptionReportingStage.java:37) at software.amazon.awssdk.core.internal.http.pipeline.stages.ExecutionFailureExceptionReportingStage.execute(ExecutionFailureExceptionReportingStage.java:26) at software.amazon.awssdk.core.internal.http.AmazonSyncHttpClient$RequestExecutionBuilderImpl.execute(AmazonSyncHttpClient.java:198) at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.invoke(BaseSyncClientHandler.java:122) at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.doExecute(BaseSyncClientHandler.java:148) at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.execute(BaseSyncClientHandler.java:102) at software.amazon.awssdk.core.client.handler.SdkSyncClientHandler.execute(SdkSyncClientHandler.java:45) at software.amazon.awssdk.awscore.client.handler.AwsSyncClientHandler.execute(AwsSyncClientHandler.java:55) at software.amazon.awssdk.services.dynamodb.DefaultDynamoDbClient.transactWriteItems(DefaultDynamoDbClient.java:4079)

Possible Solution

We are using AWS Lambda to call DynamoDB. The DDB client is configured to use UrlConnectionHttpClient (which I see was changed in this commit between 2.10.59 and 2.10.60 - may be unrelated but thought I would let you know)

• AWS Java SDK version used: fails with 2.10.60 and above
• JDK version used: Java 8
• Operating System and version: AWS Lambda

[debora-ito]

@sihutch So according to the DynamoDB service team there’s a known issue where if you delete and re-create tables with the same name some of the requests result in InternalServerError. They have a task to fix this in their backlog.

Marking this as closing soon. Let us know if you have any other question or concern.

[debora-ito]

@stuartleylandcole thank you for the follow-up. Glad you’re not getting bit by this anymore.