Starting Sept 13th the Google Tasks BatchRequest update workflow is triggering a 400 error return "Duplicate Request ID in Batch Request" within an application that has remained stable for years. I can't find anything in the request that indicates a duplicate request id. Anyone have any idea what's up? Did Google change something?
Here's a copy of the response I'm receiving when sending a simple batch task insert request ...
[{
"error": {
"code": 400,
"message": "Duplicate Request ID in Batch Request: ",
"errors": [
{
"message": "Duplicate Request ID in Batch Request: ",
"domain": "global",
"reason": "badRequest"
}
],
"status": "INVALID_ARGUMENT"
}
}]
UPDATE
While investigating this issue I found that Google made a change that now requires the Content-ID
header on each batch request item. This header is currently not set when using the .Net Google.Apis.Requests.BatchRequest
class.
To work around this I was able to create a new local implementation of Google.Apis.Requests.BatchRequest and inject a "Content-ID" header then creating each request entry.
private static long _id = 0;
[VisibleForTestOnly]
internal static async Task<HttpContent> CreateIndividualRequest(IClientServiceRequest request)
{
HttpRequestMessage requestMessage = request.CreateRequest(false);
string requestContent = await CreateRequestContentString(requestMessage).ConfigureAwait(false);
var content = new StringContent(requestContent);
content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/http");
content.Headers.Add("Content-ID", (_id++).ToString());
return content;
}
Update 2021/09/28:
This issue has been marked as fixed and you shouldn't be experiencing this anymore:
Original answer:
This doesn't seem to be limited to the library, nor to Tasks API, since it's happening at least in Calendar API too.
Now the batch endpoints seem to require
Content-ID
to be provided in the request, so it has to be added manually if the library doesn't do it.It's still not clear whether this is an expected change of behavior or not.
It has been reported in the .NET library GitHub:
And also in Google Issue Tracker:
I'd suggest starring the referenced issue in Issue Tracker in order to help prioritizing it (if this is an expected behavior, at least it should be mentioned in the documentation that
Content-ID
has to be provided).