Custom serializer breaks query

We are continuously addressing and improving the SDK, if possible, make sure the problem persist in the latest SDK version.

Describe the bug The options exposed for the built-in serializer are limited only to changing the name. Additional changes requires a custom serializer. However, any modifications in the custom serializer are not used when performing a query, making the option mostly useless.

To Reproduce

• Implement a custom serializer using example code.
• Store data
• Try to query the data with expression or LINQ

Example data:

enum CustomerRole {
  Customer,
  Manager
}
record Customer(string Id, string Name, CustomerRole Role);

var results = (await _container.GetItemLinqQueryable<Customer>().Where(x => x.Role == CustomerRole.Customer)).ToList();

Generated document (with custom serializer):

{
  "name": "John Doe"
  "role": "Customer",
  "id": "..."
}

Expected behavior The generated SQL should follow the settings on the custom serializer, i.e.: WHERE c.role == "Customer"

The results variable should contain the customer element.

Actual behavior The generated SQL follows the default serializer and returns wrong name and value, i.e.: WHERE c.Role == 0

The results variable is always empty.

Environment summary SDK Version: 3.28 OS Version: any

Additional context An additional problem is that when setting a default serializer as in the example, it is not possible to also set the SerializerOptions, so all queries will fail unless each instantiated query also has specific serializer options set. This happens in the linked example as well, because the naming convention is changed.

This is similar to issues #3207 and #2685.

[ealsur]

@jackbond Should be included in the next release, yes.

[jackbond]

At this point, I’m beginning to wonder if anyone other than Scott Guthrie can ensure this bug is resolved. Seriously, what is it going to take??? It’s 2023, System.Text.Json has been out FOR YEARS, and the Cosmos team continues to whistle past graveyards and simply acts like there isn’t a problem. Here’s an idea, publish a completely separate NuGet package that replaces every usage of Newtonsoft with STJ. We don’t need custom serializer support, NOBODY DOES. We need System.Text.Json support and we needed it YEARS AGO!!!