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
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.
Most helpful comment
To add to this, I encountered the issue again with another method that is querying a Dynamo table.
Same as before,
base
refers toDynamoDBContext
.QueryAsync
is returning an object of typeAsyncSearch
and theGetRemainingAsync()
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 aSearch
object and not anAsyncSearch
object. Maybe that has something to do with it?