Aws-sdk-net: Erroneous call being made to DynamoDB with unexpected table name from AsyncSearch.GetRemainingAsync()

Created on 23 Jan 2019  路  4Comments  路  Source: aws/aws-sdk-net

I was using Fiddler 4 to monitor API calls made by our application and came across something odd that I'm looking for some closure to.

using the following code:

public async Task<IEnumerable<T>> GetAllItemsAsync()
        {
            var asyncSearch = base.ScanAsync<T>(null, config);

            return await asyncSearch.GetRemainingAsync();
        }

base in this context is referring to the DynamoDBContext class. The config parameter in base.ScanAsync<T>(null, config) is an instance of DynamoDBOperationConfig that has the OverrideTableName property set to my correct table name (I'll call it "MyTable" for this example). I'll call T "MyClass".

I get all of my items back successfully from the endpoint that calls into this method. I get a 200 response with the expected response body and the correct "MyTable" as the table name. However, in Fiddler I see a secondary call that goes out immediately after the successful one with a request body of {TableName : "MyClass" } and has a 404 response. It's not affecting the application at all and not being caught anywhere. It's just this extra call in the background that happens.

The only thing I could find that points to "MyClass" is in the asyncSearch object:
asyncSearch.SourceContext.StorageConfigCache.Cache.Items[0].Value.BaseTableName

I changed the code to:

public async Task<IEnumerable<T>> GetAllItemsAsync()
        {
            var table = base.GetTargetTable<T>(config);
            var search = table.Scan(new ScanOperationConfig());
            var results = await search.GetRemainingAsync();

            return base.FromDocuments<T>(results, config);
        }

And this no longer has that extra second request. I'm just curious if anyone could provide any insight as to why this is. I'm not sure if it's a legitimate issue or if it's just the way the code is implemented.

AWS SDK DynamoDBv2 package version: 3.3.2.1
.NET Core version: 2.1.402
Operating System: Windows 10 Pro v10.0.17134

closed-for-staleness guidance moduldynamodb response-requested

Most helpful comment

To add to this, I encountered the issue again with another method that is querying a Dynamo table.

public async Task<List<T>> QueryByKeyAsync(string key, string indexName = null)
        {
            var operationConfig = new DynamoDBOperationConfig
            {
                OverrideTableName = this.config.OverrideTableName,
                IndexName = indexName,
            };

            var querySearch = base.QueryAsync<T>(key, operationConfig);

            return await querySearch.GetRemainingAsync();
        }

Same as before, base refers to DynamoDBContext.

QueryAsync is returning an object of type AsyncSearch and the GetRemainingAsync() call has two requests go out according to Fiddler. One that is correct and returns the expected results, and one that goes out with a body of {TableName : "MyClass" }.

I noticed that in my example in the original post that does not produce a second call, I am using the GetRemainingAsync() method from an instance of a Search object and not an AsyncSearch object. Maybe that has something to do with it?

All 4 comments

To add to this, I encountered the issue again with another method that is querying a Dynamo table.

public async Task<List<T>> QueryByKeyAsync(string key, string indexName = null)
        {
            var operationConfig = new DynamoDBOperationConfig
            {
                OverrideTableName = this.config.OverrideTableName,
                IndexName = indexName,
            };

            var querySearch = base.QueryAsync<T>(key, operationConfig);

            return await querySearch.GetRemainingAsync();
        }

Same as before, base refers to DynamoDBContext.

QueryAsync is returning an object of type AsyncSearch and the GetRemainingAsync() call has two requests go out according to Fiddler. One that is correct and returns the expected results, and one that goes out with a body of {TableName : "MyClass" }.

I noticed that in my example in the original post that does not produce a second call, I am using the GetRemainingAsync() method from an instance of a Search object and not an AsyncSearch object. Maybe that has something to do with it?

I'm having this exact same issue. I've noticed that the call to GetRemainingAsync makes a call to the document cache with the DynamoDBOperationConfig fixed to null, which may mean that it reverts to using the document model class name as the table name, which I'm guessing results in a cache miss and an erroneous DescribeTable request.

Hi @jpwinz91,

Good afternoon.

I was going through the issue backlog and came across this question. I do see an input from @drdanick. Please confirm if this issue could be closed.

Thanks,
Ashish

This issue has not recieved a response in 2 weeks. If you want to keep this issue open, please just leave a comment below and auto-close will be canceled.

Was this page helpful?
0 / 5 - 0 ratings