HttpRequestMessageFactory.CreateRequestMessage, timeout already set within builder causing ArgumentException

[RikvanDoorn]

I'm suspecting this has something to do with retrying, since it usually happens after 1/2 activations of the (exponential) retry policy after timeout. It appears the "timeout" key within the UriQueryBuilder is already set, and the method tries to add it as well without proper check, causing an exception.

[RikvanDoorn]

exception.txt

[RikvanDoorn]

My proposed fix is adding a check to check whether or not the key already exists within the builder. If it does already exist, either add a setter to the this[] of the builer, or just use the currently set value and ignore the new value.

Also probably add the "timeout" string to the QueryConstants class, for good measure.

[erezvani1529]

@RikvanDoorn thanks for reporting this issue. I will look into this issue and take a fix for our next release v9.1.

-Elham

[kristianhald]

I just debugged this, as we are having the same problem.
The problem happens, if you set 'TableRequestOptions.ServerTimeout' and a retry occurs.

To be more specific on line 91 in Executor.cs a call to 'cmd.BuildRequest' is made, which is inside a retry-while-loop. A new builder is created on line 90, but if you look at how the cmd.BuildRequest is setup, then this builder is not used (TableQueryGeneric.cs line 146):

queryCmd.BuildRequest = (cmd, uri, --->queryBuilder<---, cnt, serverTimeout, ctx) => TableOperationHttpRequestMessageFactory.BuildRequestForTableQuery(uri, --->builder<---, serverTimeout, cnt, ctx, requestOptions.PayloadFormat.Value, client.GetCanonicalizer(), client.Credentials);

The builder provided as a parameter 'queryBuilder' is not used, but instead a builder created during the QueryImpl method call is used (The 'builder' variable). It is this builder that is provided with 'timeout' twice, if a retry occurs in the executor.