Enable JSON field name attributes to specify cross-hierarchy path mapping

[zms9110750]

I want to silently complete serialization. So I specified the default converter using attributes.
However, I only want to modify certain parts of the JSON structure to match my entity.
For example, extracting fields from child objects as peer fields.
But for the remaining fields, I need them to be serialized using the default method.

Now, when I get the default converter, it recognizes the attributes and returns to my converter.
What should I do?

[zms9110750]

This is DeepSeek’s JSON:

"message": {
    "content": "string",
    "reasoning_content": "string",
    "tool_calls": [
        {
            "id": "string",
            "type": "function",
            "function": {
                "name": "string",
                "arguments": "string"
            }
        }
    ]
}

I already have a Message class, but it doesn’t include tool calls.
I don’t want to create a separate inherited class just for this—it’s semantically inappropriate.
Instead, I want to extract tool calls as peer fields alongside the message.
However, I can’t add a custom converter to the Message class, because doing so would prevent me from controlling the fields at the same level as the message.
The object containing the message has many other fields, and I don’t want to manually assign values to each one.

Currently, my workaround is:

1. Fetch the network response.
2. Convert it to a JsonObject.
3. Process the required nodes.
4. Then perform serialization.

[elgonzo]

The approach with a custom converter should work.
You must however apply the converter to the properties/fields of interest using for example the [JsonConverter] attribute and not adding it to the JsonSerializerOptions. This way, the converter will only be used when (de)serializing these specific properties/fields and not for any other instances of the types supported by the converter.

EDIT: Regarding your 2nd comment, which came at the same time i posted this comment here, it seems to looks like that [JsonConverter] attribute alone might not do the trick...

[elgonzo]

Regarding your update (your 2nd comment), what is the actual type you want to deserialize Message into? I unfortunately don't know what exactly "peer fields alongside the message" is supposed to mean in terms of the desired shape of the deserialization result.

Now, when I get the default converter, it recognizes the attributes and returns to my converter.

If your intent is to get STJ's default converter, don't obtain it from the JsonSerializerOptions instance already configured with your converter. Try using JsonSerializerOptions.Default instead (which should be oblivious to any custom converter). For this to work, however, the type(s) you want to get STJ's default converter for must not be annotated with the [JsonConverter] attribute.

[zms9110750]

i want to

"choices" : {
"message": {
    "content": "string",
    "reasoning_content": "string",
}
  "tool_calls": [
        {
            "id": "string",
            "type": "function",
            "function": {
                "name": "string",
                "arguments": "string"
            }
        }
   ]
}

[zms9110750]

now, i class is

public record ChatChoice(
			[property: JsonPropertyName("message"), JsonProperty("message")]AssistantMessage Message,
			[property: JsonPropertyName("logprobs"), JsonProperty("logprobs"),
			System.Text.Json.Serialization.JsonConverter(typeof(LogprobChatTextJsonConverter)),
			Newtonsoft.Json.JsonConverter(typeof(LogprobChatNewtonsoftConverter))] Logprob[] Logprobs,
			ToolCall[]? ToolCalls
		) : ChoicesCommon;

if JsonConverter use to ChatChoice , i dont know handle ChoicesCommon field.
if use to Message , i can't handle ToolCall[]

[elgonzo]

I feel like your current approach is both the most convenient and also the least trouble-some approach when considering using the source-gen JsonSerializerContext and/or trimming/AoT scenarios. (It would be nice to have a feature for using a JsonPath instead of property name as a mapping between a .NET type property and some json value, but unfortunately there is none so far...)

One concern here is that unless you want to lean on the crutch of reflection, the ChatChoice instance has to be instantiated at once with both the Message and ToolCalls instances available to be passed into its constructor. Which means, construction and population of ChatChoice has to be either single-pass or you wouldn't be able to use JsonSerializerContext (assuming that this is desirable to you).

One alternative approach is to deserialize the values for the ChatChoice constructor individually (you can't rely on the [JsonPropertyName] attribute annotation in this case) -- for example by reading the json input into a lean JsonElement and deserializing the constructor values from the respective json properties in that JsonElement -- and then construct the ChatChoice instance with these individually deserialized components.

Another alternative is to use a two-pass deserialization approach which will need to rely on reflection (due to the need of populating init properties after a record instance has been created):

1. Read message json into JsonElement
2. Deserialize into JsonElement into ChatChoice instance (using STJ's default converter; that mean don't annotate ChatChoice with [JsonConverter])
3. Populate deserialized ChatChoice instance with the content from JsonElement.TryGetProperty("tool_calls"u8, out var toolCallsJson)

The problem here is the lack of a public Populate API in STJ (which i feel is unlikely to be coming anytime soon, due to STJ source-gen serializer being unable to modify init properties). There is workaround suggested in #78556 (comment) which you might perhaps want to adapt to your needs. Whether it would be worthwhile for you to incorporate such a "Populate" workaround into your code base and maintain it over just keeping your current approach of using and modifying JsonObject is ultimately for you to decide. (Personally, i am not convinced that's worthwhile; but i am also not really aware of the entire scope of your problem, how many records, how many properties are affected by the mismatch of the json structure and your .NET types, so it's your call...)