Respect JsonSerializerOptions casing for property names in validation errors

[Copilot]

Summary

When configuring JSON serialization options with a custom property naming policy (like camelCase), validation error responses were not consistently following the same naming policy for property names. This created a disconnect between what clients send/expect and what the validation errors contained.

The implemented changes ensure validation errors respect the configured JSON naming policy, making them consistent with the rest of the API's JSON formatting.

Changes

• Added a SerializerOptions property to ValidateContext to access JSON naming policies
• Modified the ValidationEndpointFilterFactory to pass the JSON options from DI to the validation context
• Implemented property formatting that respects PropertyNamingPolicy for error key names
• Added comprehensive tests for different naming policies, nested properties, and array indices
• Properly handles complex property paths with dots and array indices (items[0].productName → items[0].productName)

Before

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.41",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
    "LastName": [
      "The LastName field is required."
    ]
  }
}

After

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.41",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
    "lastName": [
      "The LastName field is required."
    ]
  }
}

The implementation preserves the full compatibility with existing usage while ensuring that property names in validation errors now follow the configured naming policy.

Fixes #61764.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• cdn.fwupd.org
  • Triggering command: /usr/bin/fwupdmgr refresh (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[captainsafia]

Good start! Left some comments inline.

[Copilot]

Good start! Left some comments inline.

I've addressed all the inline comments. Made the SerializerOptions property internal, removed the test file, and updated ValidationEndpointFilterFactory to use the internal property via reflection. All changes in commit 216406a.

[Copilot]

@captainsafia Unfortunately I hit an unexpected error while processing your comment. I've automatically reported this to GitHub.

You can ask me to try again later by mentioning me in a new comment.

If you want to contact GitHub about this error, please mention the following identifier so they can better serve you: 590bfda1-76e1-4d10-a5c3-2f6bb862c94c

Sorry for the inconvenience!

[captainsafia]

@copilot Let's try to address the review comments I left for you earlier. You were on the right track with making the SerializerOptions property public and setting it in the ValidationEndpointFilterFactory based on the way our assembly references are structured.

[captainsafia]

We're almost there! One more comment. Also, be undo all the changes you made to the package.json files and remove the package.json.bak files.

[captainsafia]

@copilot Revert any changes made to package.json and package-lock.json files to their state in main.

[captainsafia]

@copilot I've made some fixes to the implementation and want you to follow up on some things, including:

• HasDisplayAttribute is called each type a type is validated. Can you update the implementation to call it once and cache it on the ValidatablePropertyInfo?
• The performance of the FormatComplexKey method can probably be improved. Can we cache the JSON naming policy on the ValidateContext? Are there other improvements that we can make here?

[Copilot]

@copilot I've made some fixes to the implementation and want you to follow up on some things, including:

• HasDisplayAttribute is called each type a type is validated. Can you update the implemen...

I've implemented both performance improvements in commit 409bb34:

1. HasDisplayAttribute caching: Added _hasDisplayAttribute field to cache reflection result in constructor, eliminating repeated calls during validation
2. FormatComplexKey optimization: Cached the JSON naming policy in ValidateContext and made the method static with the naming policy as a parameter, reducing property access overhead and redundant null checks

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

[captainsafia]

@DeagleGross @BrennanConroy Would love your review n this PR. Outside of the prompting, I ended up making local changes on 59069f7 (#62036) and f035b35 (#62036).

Some things here:

• We need to add JsonSerializerOptions as a property on the ValidateContext since we don't have access to the JsonOptions type in the Http.Abstractions assembly in order to be able to resolve it ourselves in the ValidatableTypes. I think that probably makes the most sense for frameworks who are building on top of the abstractions API anyways.
• When I asked Copilot to add support for formatting the keys in the validation result, it used the strategy that I removed in this commit. I played around with why it chose this instead of relying on the fact that we format the names in the ValidatableTypes. The only impacted scenario was the IValidatableObject one so I created a specific one for tat.
• The precedence ordering is [Display(Name = "")], then [JsonPropertyName] then the JSON naming policy.

[mikekistler]

This looks great! I can't say I understand how this works but just looking at the changes to the expected results of the tests, this is a very welcome change.

[halter73]

• We need to add JsonSerializerOptions as a property on the ValidateContext since we don't have access to the JsonOptions type in the Http.Abstractions assembly in order to be able to resolve it ourselves in the ValidatableTypes. I think that probably makes the most sense for frameworks who are building on top of the abstractions API anyways.

Would this be better on ValidationOptions? We could use IPostConfigureOptions to set it once.

We should also create an API proposal issue for it. I bet copilot would do well at taking our issue template and this PR as inputs and creating an issue.

• The precedence ordering is [Display(Name = "")], then [JsonPropertyName] then the JSON naming policy.

Does [Display(Name = "")] affect how the type gets serialized? And if not, shouldn't the validation errors match what gets serialized?

Also, do we have a test that verifies what happens when you have both [Display(Name = "")] and [JsonPropertyName] on the same property?

[halter73]

Is this true? It's not like we're asking for the one and only [JsonPropertyName] used for the type represented by the ValidatableTypeInfo here. That would be impossible. Instead, we're asking for the [JsonPropertyName] for each of its member properties, right? If we didn't have any context of the property being validated here, how are we getting the name of the property at all let alone the proper casing?

I think we should probably respect all the same attributes we do in ValidatablePropertyInfo, namely [Display] (if we keep doing that) and [JsonPropertyName].

[halter73]

Is this just redundant? Could it be that memberName already formatted here? I haven't run it, so it might not be the case, but we should definitely add some tests with a camel cased PropertyNamingPolicy and a capitalized first letter in the [JsonPropertyName] attribute.

[halter73]

Suggested change

	[Fact]
	[Fact]

[BrennanConroy]

Feels weird to grab the attribute, but then never actually use the value from the attribute. At that point, why not just use string.IsNullOrEmpty(DisplayName)?

[halter73]

Good catch. I find it sometimes helps to ask copilot not to add any fields if you don't think it should be necessary.

[BrennanConroy]

Putting it on the record that I'm not a fan of adding this to the ValidateContext. Especially if we're wanting to eventually move this API into dotnet/runtime.

[halter73]

What do you think about moving it to ValidationOptions as I suggest here?

[halter73]

Why is this necessary?