[Client bug]: Microsoft.Graph 5.4.0 generates invalid request Uris for GetDirectRoutingCallsWithFromDateTimeWithToDateTime

[sopelt]

Describe the bug
When calling CallRecordsGetDirectRoutingCallsWithFromDateTimeWithToDateTime the current Microsoft.Graph SDK/client generates a wrong request URL (resulting in HTTP 404) and invalid filter parameter format (resulting in HTTP 404 as well as the route doesn't seem to match). This is a followup/related to #1443 and potentially microsoft/OpenAPI.NET.OData#262 and I hope @andrueastman will have a look at this as well.

As far as I can tell this did not work yet in any dotnet graph SDK version.

To Reproduce

var response = await GraphServiceClient.Communications.CallRecords.CallRecordsGetDirectRoutingCallsWithFromDateTimeWithToDateTime(fromDateTime, toDateTime).GetAsync();

Expected behavior
Call records are being returned.

Screenshots

Client version
https://www.nuget.org/packages/Microsoft.Graph/5.4.0

Desktop (please complete the following information):

• Win11
• .NET 6.0

Workaround

The following snippet shows how to override the url template and encode the parameters in the working format:

var dateFormat = "yyyy-MM-dd";

var parameters = new Dictionary<string, object>
{
    { "fromDateTime", fromDateTime.ToString(dateFormat, CultureInfo.InvariantCulture) },
    { "toDateTime", toDateTime.ToString(dateFormat, CultureInfo.InvariantCulture) }
};

var requestBuilder = new CallRecordsGetDirectRoutingCallsWithFromDateTimeWithToDateTimeRequestBuilder(parameters, GraphServiceClient.RequestAdapter);
var requestInfo = requestBuilder.ToGetRequestInformation();
requestInfo.UrlTemplate = "{+baseurl}/communications/callRecords/getDirectRoutingCalls(fromDateTime={fromDateTime},toDateTime={toDateTime}){?%24top,%24skip,%24search,%24filter,%24count}";
var response = await GraphServiceClient.RequestAdapter.SendAsync(requestInfo, GetDirectRoutingCallsWithFromDateTimeWithToDateTimeResponse.CreateFromDiscriminatorValue);

[andrueastman]

Related to microsoft/OpenAPI.NET.OData#365

[baywet]

After further investigations:

GET https://graph.microsoft.com/v1.0/communications/callRecords/microsoft.graph.callRecords.getDirectRoutingCalls(fromDateTime=2023-03-25,toDateTime=2023-03-29)?$whatif

{
    "Description": "Execute HTTP request",
    "Uri": "https://plat.teams.microsoft.com/communications/callRecords/microsoft.graph.callRecords.getDirectRoutingCalls(fromDateTime=2023-03-25,toDateTime=2023-03-29)",
    "HttpMethod": "GET",
    "TargetWorkloadId": "Microsoft.IC3.DataPlatform"
}

GET https://graph.microsoft.com/v1.0/communications/callRecords/getDirectRoutingCalls(fromDateTime=2023-03-25,toDateTime=2023-03-29)?$whatif

{
    "Description": "Execute HTTP request",
    "Uri": "https://plat.teams.microsoft.com/communications/callRecords/microsoft.graph.callRecords.getDirectRoutingCalls(fromDateTime=2023-03-25,toDateTime=2023-03-29)",
    "HttpMethod": "GET",
    "TargetWorkloadId": "Microsoft.IC3.DataPlatform"
}

GET https://graph.microsoft.com/v1.0/communications/callRecords/callRecords.getDirectRoutingCalls(fromDateTime=2023-03-25,toDateTime=2023-03-29)?$whatif

{
    "Description": "Execute HTTP request",
    "Uri": "https://plat.teams.microsoft.com/communications/callRecords('callRecords.getDirectRoutingCalls(fromDateTime=2023-03-25,toDateTime=2023-03-29)')",
    "HttpMethod": "GET",
    "TargetWorkloadId": "Microsoft.IC3.DataPlatform"
}

So it's effectively AGS messing up the request. We should probably open an ICM on them.

[andrueastman]

Thanks for this @baywet

Taking a look at the URI's above, it looks like the first two generate the same URI with the full namespace and with the whole namespace stripped.
https://plat.teams.microsoft.com/communications/callRecords/microsoft.graph.callRecords.getDirectRoutingCalls(fromDateTime=2023-03-25,toDateTime=2023-03-29)

While the third one generates
https://plat.teams.microsoft.com/communications/callRecords('callRecords.getDirectRoutingCalls(fromDateTime=2023-03-25,toDateTime=2023-03-29)')

As the metadata does not have an alias for the microsoft.graph.callRecords namespace I suspect that it might be an error with the indiscriminate stripping of the microsoft.graph prefix for methods.

[baywet]

ah, so there's no alias being defined? then yes, it's an issue of the conversion process. Thanks for calling this out.

[andrueastman]

This would be the same for #1691 as the microsoft.graph.security namespace also does not have an alias.