Oops! I goofed on the answer and I've updated it (slightly). I guess I didn't paste something.

1. You don't need to implement WriteAsync. I provided ErrorObjectWriter a while back for this interop scenario. It will do all of the work. The only thing you have to change is the extra condition in CanWrite a la override.
2. I goofed. All you need to do is include the partial class definition (see above) and the JSON source code generator will do the rest. This optimizes the serialization process. The JSON setup is how the infrastructure is configured so when it sees ErrorObject it knows how to serialize it.

If you really want to implement WriteAsync, you could. It's incredibly simple:

The reason you need a ConditionalErrorObjectJsonContext is because I presumed that the only reason anyone would ever want to customize this behavior is to add (or perhaps remove) part of the serialization, which requires an alternate options. Conflicting sets of options would be problematic. You have a rare case where you have custom matching rules, but the same serialization. It's a small about of extra work, but not much.

Hi Chris (@commonsensesoftware).

Thank you.

If I understand everything. Since my ConditionalErrorObjectWriter is derived from ErrorObjectWriter, if my overridden CanWrite method returns false, than the next ErrorObjectWriter in the chain will be called. Now, if CanWrite returns true, the WriteAsync implementation of ConditionalErrorObjectWriter will be called, which is the base class implementation of WriteAsync. That method will still put out the RFC version of the problem details.

Below is a sanitized response from the current API. It always contains the same fields whether an error occurred or not. The input to the API call is a list of IDs. It is possible that one or more ids are invalid, but the rest are valid. As a result, the response will contain items inside the recommendations array and the invalid ids in the errors array.

{
 "algocd": "some string",
 "recommendations": []
 "errors": [],
 "isdefault": true,
 "isimported": false,
 "server": "ProductionServer",
 "setname": "application generated",
 "updateTimes": {}
}

I haven't figured out how this will be handled in the V2 API, however, it would probably be similar, but the format of the errors array would resemble a problem detail.

I'm beginning to think I might be better off just surpassing the new model invalid behavior by setting SuppressModelStateInvalidFilter = true and just using my own logic. I guess I need to finish the port and run my test suite. Then I can review the response being sent back, and decide how to handle exceptions versus bad input data.

If I decided that using a custom ErrorObjectWriter is the correct approach, I think I would be better off just implementing the IProblemsDetailsWriter.

Sorry for sending you down a rabbit hole,

Thank you for all the help.

It sounds like you have a mixture of valid and invalid results in a single response. In this case, neither Problem Details nor Error Object is probably the correct output. If you want to have an error look like Problem Details or an Error Object, there's nothing wrong with that.

A side note about Problem Details is that it differs from Error Object by more than just its JSON attributes and structure. Problem Details is always returned with the base media type application/problem so that a client knows what they are getting. It might otherwise be ambiguous. application/problem+json and application/problem+xml are the well-known suffix types, but Problem Details are not limited to those formats. The Error Object, on the other hand, is derived from the OData protocol (if you didn't know). It can also be represented as JSON or XML, but it does not have well-defined media type. A client has to assume that if they receive content in an unsuccessful response, that it should be an Error Object, but there is no guarantee of that.