Uri's malformed when using a colon to pack partition keys.

[richard-einfinity]

Describe the bug

Uri's are malformed when the id contains a colon.

To Reproduce

Steps to reproduce the behavior:

Generate client side id's containing colons and attempt to update or delete the entity's after the initial sync.

Expected behavior

Entity's update and delete after pushing changes.

What platforms?

Note: Any bug or feature request that is opened for an unsupported environment will be automatically closed.

• Server:

  • Version of dotnet being used to compile? net8.0
  • Library versions? Microsoft.AspNetCore.Datasync 6.1.0
  • What database are you using? CosmosDb
  • Where are you running the server? Azure Web Apps
  • GitHub repository containing the code (optional, but helps!)

• Client:

  • What platform (Android, iOS, Windows, etc.) versions are you running on? Maui (Android / iOS)
  • Does it happen in an emulator / simulator, or only on a real device? all
  • Version of dotnet being used to compile? net8.0
  • .NET Runtime Environment (WPF, UWP, WinUI3, MAUI, etc.): Maui
  • Datsync Toolkit NuGet versions? 8.0.2
  • GitHub repository containing the code (optional, but helps!)

Additional context

We we're previously discussing strategy's for dealing with partition keys etc on the previous version of the sdk. I opted for packing the id field with the client generated id and the partition key separated by a colon.

I've updated the client library to the latest version and it looks as though the mechanism for constructing the request uri's is now causing the uri's to become malformed. It would seem that if the string passed as the relative part of the Uri constructor contains a colon the constructor assumes its an absolute uri containing a schema and returns only this portion of the uri.

So here

Datasync/src/CommunityToolkit.Datasync.Client/Offline/Operations/DeleteOperation.cs

Line 25 in fb3018d

using HttpRequestMessage request = new(HttpMethod.Delete, new Uri(endpoint, operation.ItemId));

and here

Datasync/src/CommunityToolkit.Datasync.Client/Offline/Operations/ReplaceOperation.cs

Line 25 in fb3018d

using HttpRequestMessage request = new(HttpMethod.Put, new Uri(endpoint, operation.ItemId))

Where endpoint might be https://dummysyncapi.azurewebsites.net/tables/item and id is 93AE2D56-CA9B-4397-B59E-EAB245DDE9E8:AF1E3CBC-A58D-4165-A18F-4C2B35021D02

new Uri(endpoint, id) returns 93AE2D56-CA9B-4397-B59E-EAB245DDE9E8:AF1E3CBC-A58D-4165-A18F-4C2B35021D02

The previous implementation combined the path of the endpoint and the id as a string before combining it with the base uri to make the absolute uri.

[richard-einfinity]

Possible solution. Update MakeAbsoluteUri signature to take optional item id parameter with default value of string empty and combine the id inside that method after the trailing slash.

Datasync/src/CommunityToolkit.Datasync.Client/Offline/Operations/ExecutableOperation.cs

Line 26 in fb3018d

internal static Uri MakeAbsoluteUri(Uri? baseAddress, Uri relativeOrAbsoluteUri)

[adrianhall]

Good catch - I suspect that there are other areas where this occurs. Is this also a problem in the "online" operations?

[richard-einfinity]

hi @adrianhall

Just looking at the online operations and the Uri is built by concatenating the string so it avoids this issue.

Datasync/src/CommunityToolkit.Datasync.Client/Service/DatasyncServiceClient.cs

Line 450 in fb3018d

builder.Path = $"{builder.Path.TrimEnd('/')}/{id}";

Happy to submit a PR if your agreed with the suggested solution.

Cheers

Rich

[adrianhall]

Sounds like a reasonable fix to me. It was pretty much what I was going to do as well. Submit the PR - make sure all the tests pass.